The Problem: Create a new Portal for the Company’s clients.
The Company: B2B Telecom Company specialized in services for the Wholesale and Multinational sectors.
The Story
Introduction
After a reorganization, the Marketing Department has been set-up almost from scratch. The new Director and her team have brought new ideas and new projects. Among those projects they have come with the idea of creating a new customer’s portal. Existing portals (second version of a five years old support portal and two years old self-provisioning portal) did not appeal the new team for different reasons or were difficult to evolve. So, after months of discussions among management, the project came to my desk. The initial budget was 385 K€.
The budget.
The first thing I did was to review the budget and where it was assigned to. Not only the budget, but also the architecture was already designed by the corresponding department. The Portal was supposed to be developed as a “Community” within the cloud CRM (Customer Relationship Management) solution, but it would need integrations with the ticketing platform (also cloud based), the on-premise provisioning system (the “Fullstack”) and the Identity Manager (IM) which is on-premise too. Besides, following the “API First” paradigm, everything offered through the Portal’s GUI should have its corresponding API published and ready to use. Apart from the aforementioned main applications, we also had the following related platforms: An ESB (Enterprise Service Bus) to act as integration platform and an API Gateway with its own Portal for publishing the APIs.
The initial budget split was:
| CRM | 195k |
| Fullstack | 85,6k |
| IM | 25k |
| Professional Services (PM & QA) | 77,4k |
| TOTAL | 383k |
So, apparently, neither there was anything for the ESB nor for the API Gateway. Besides, giving past experiences, the cost for what was needed to be developed in the Fullstack seamed very insufficient.
In my opinion, the most important part of the projects is the Initiation. This is the phase in which you can influence more. If you think the project is underestimated in budget or time, that’s the right time to push to get those things corrected before actual start. Also, it is the time to bring the proper people to the team. Having said that, I pushed to start talking with the internal stakeholders to understand the requirements and with the providers to get their inputs. I have not mentioned that within the Company, those kinds of big developments are externally contracted. Therefore, after some additional weeks we reached to the following budget split:
| CRM | 195k |
| Fullstack | 190k |
| IM | 15k |
| Professional Services (PM & QA) | 77,4k |
| Ticketing system | 5,4k |
| ESB | 27k |
| API GTW | 16k |
| TOTAL | 525,8k |
Which means a 142,8k difference from what was initially budgeted. Fortunately, there were some reserves coming from other initiatives that could be diverted to this project and the gap could be covered.
The Plan.
In this kind of projects, there is always a mean supplier, in this case it was the one that provided the CRM development. The Portal was going to be developed as a “community” within the CRM which, in fact, is the number one cloud solution in the market. So, we asked our reference provider to give us its best plan to develop that Portal.
They came with a very rough plan in a one-slide PowerPoint. It was an agile development, with 7 sprints of 4 weeks each, although the first one was not really a sprint, but the project preparation (the typical Sprint 0).
So, with this backbone, we talked with the 2nd main vendor which was the Fullstack provider. They had to provide with APIs to access its ordering and inventory system and, as well, they had to develop some changes in its self-service Portal to facilitate the integration with the main Portal in the CRM. With this scope, they came with a completely waterfall approach with a very inflexible scheme. So we had to work very hard to negotiate the integration of the waterfall with the agile main project.
At the end we ended with 2 releases of the waterfall project plan, first of it delivered just before starting with Sprint 4 and second delivered before Sprint 5. In this way, at least, we ensured that the Agile Development Team had what they needed to integrate the deliveries of the Fullstack team. In the contrary, one of the most important risks was that, in order not to increase the project budget, the Fullstack provider had to free its resources before the overall E2E and UAT tests, which means, we had to test its part in a very early stage of the portal development and we would have to give them the GO for Production before the Portal has been ensembled and fully tested.
This reminds me that we also had to integrate the work of the QA testing team and the work needed to deploy the software in the UAT and Production environments. This is one of the main difficulties of this kind of projects. Development is done in an agile way in a development environment, but the integration with the other teams and the E2E tests normally have to be done in another environment which in this case is called UAT environment, but it can be Integration, Pre-production or any other naming convention.
To minimize the risk, but not to increase a lot the integration effort, we decided to perform 2 main deployments to Production. However, we planned to deploy 4 times (after 4 of the 7 sprints) to the UAT environment to do the integration and perform the “official” QA testing.
In theory, Scrum encourages to perform the testing inside the development sprints, but in the “real” world, when you have to integrate different developments from different vendors and you have a separate team to perform the testing this leads to separate the testing from the development effort also. In any case, it is Development Team responsibility to release good software with enough quality.
In the above Project Plan, you can see the relationships between the 2 main suppliers. At the top and in blue color, the main team who was working in fully agile methodology. At the botton, in yellow and orange, there are the summarized tasks of the 2nd most important supplier, who was working in waterfall. The two red dotted arrows are the dependencies between what the 2nd team had to delivered and used by the 1st team. Also, the dark boxes and the black dotted arrows are the summarized tasks and dependencies of the QA team, who had to test both suppliers’ developments.
The Team
What is the most important thing for a project success? The team, of course. In my case, I could only choose one person, but I completely hit the target. UX/UI designer was from Marketing Department and I knew this person from past projects. She was a great professional, but very chaotic, therefore she could neither be included in the Development Team, nor work as Project Owner without ruining the whole project. So, the person I chose, was given the Project Owner role by me. She had to listen to the UX/UI designer, also other stakeholders and create and prioritize the Product Backlog. The tool we used was Jira and there she created the User Stories. Those were measured by the Development Team and chosen for the Sprint in the Sprint Planning ceremonies.
The Scrum Master was officially the project manager of the team who did the main part of the Portal, although myself and the Product Owner had to collaborate to remove all the impediments. His main role was raise those impediments and we had to remove them. Since he was from a Vendor, we had to help him in that job.
Conclusion
Reality is Hybrid. Maybe if you work in a pure Software Company, controlling all the aspects of a Software Development project, you can work using pure Agile or Scrum, but if you work in a normal Company trying to deal with different Vendors and trying to integrate different technologies, you will reach to hybrid projects. Besides, nowadays, it is crucial to incorporate some kind of agility in software projects. If a project lasts for more than a couple of months or even in those situations, the requirements will probably change. Also, in current companies, costs and staff have been cut so much that it is impossible to evaluate and analyze all the aspects of a project in its initiation or planning phases. If you do so, you would never start any project…