We are in the business of providing highly specialized software services for over 22 years now. Leading telecom vendors and mobile operators worldwide trust us to deliver complex and challenging projects for years now, they grow their business with us year-over-year and they almost never change us with a different supplier.
How did we grow such successful business relationships and why they appeal to us when they have very complex and complicated projects, or projects with very tight deadlines?
It’s about a combination of factors: we always hire excellent specialists with high level of enthusiasm, we maintain well-defined procedures and methodologies when implementing software projects, we are transparent in customer relationships, we offer ongoing technical consultancy (always think before you execute approach), we strive to understand each customer’s/specific project’s constraints and identify the best means to overcome them.
In the beginning there was waterfall… and we were all happy about it
Waterfall was the hype when considering software implementation methodology for quite some time. Project activities were done consequently and it seemed the normal, most effective way to approach a project: first project analysis, than design, implementation phase, testing, and acceptance on client’s side. The end. Happy customer and happy supplier.
But business needs changed as the increasing competition landscape made everybody want more, faster. Furthermore, technologies evolve with speed light, architectures become more and more complex as we add new systems to it, and all this must integrate smoothly. Our customers are asking for shorter time to market for each new project while they are constrained to change their requirements during the analysis, or even during implementation phase due to the fact that their business needs change too fast.
So shall we convert to the so praised Agile methodology? No, Agile is not an option for our projects. But neither waterfall…
We are implementing complex projects, having a large number of external dependencies, combining old and new technologies and involving many decision-makers. Not to forget about geographically dispersed teams. So, no, “Agile” wouldn’t help us optimize our projects. But neither would waterfall…
We have to be realistic. Agile can be applied only in about 10 % of our projects. We can not apply when we are developing complex telecom products that go live into the core of leading global mobile operators with subscriber basis of tens of millions.
So is there any life between waterfall and agile?
Yes, there is a complete universe in between that makes our life easier as project manager and as organization and it can do the same also for you.
How do we approach the most challenging projects?
We start by defining the project’s purpose, scope, goals and objectives during project initiation. In spite of this, they are refined, monitored and adjusted on a regular basis during the project. To achieve this, detailed records are maintained by Project Managers in our internal document management system.
We than move to estimates; we are working on “fixed price” model and by doing this we are sharing projects risks with our customers, therefore we need to be very thorough when doing estimations. Usually the offer is done before the requirements are completely defined. To do this, after the work effort is initially estimated taking into consideration the set of initial requirements, this is constantly refined, monitored and adjusted in case of updates on the initial requirements.
After we cover this part, the critical dependencies are defined, negotiated, and reflected in the project schedule.
In order to cover customer’s need to have “something” to start from, we deliver a first minimal solution/prototype, followed by future releases. The difference from “agile sprints” is the timeline. The initial release is at 1.5-2 months, followed by releases at 3-4 weeks.
In regards to the key roles involved, each complex project team includes an experienced project manager, technical experts from solution architects to programmers, and QA engineers. Such projects are assigned ONLY to specialists with acknowledged domain expertise and we are requesting to have the same key roles on the customer side.
All key stakeholders are all proactively involved in all phases of the projects, from project initiation through to review workshops (design, flows, functional specs, mock-ups, even code review, where such competencies are present on client side) and weekly meetings with PMs.
While the initial prototype is being produced, software requirements are being reprioritized and detailed for the next cycles, taking into consideration the feedback from business stakeholders and end users.
A detailed test plan is created, next to a RTM. In this phase we include a “continuous testing integration framework”: automated test suite, regression suites, release management plan and build procedures. Also, the test plan is being delivered to the customer to be reviewed.
Another relevant aspect is our focus on quality/thorough technical documentation. Besides design documents, user/admin/installation guides, a specific page of the project is created in our knowledge database framework. All these are of great help when a project is transferred into production, to the “care” team, but also for knowledge sharing between teams, as the project team is volatile. Going beyond its impact on project’s effectiveness, in telecoms regulations are also implying strict rules related to technical documentation, in order to verify that implemented software is following the standards. To ease our work, we sustain this project activity by having relevant templates and guidelines.
In conclusion, in order to deliver complex, good quality and dynamic projects within short timelines we have to adapt acknowledged methodologies to real life.