The Business Analysts swooped in and worked their magic on high-level design documentation and a long list of prioritized requirements. "Wonderful" declared both the (first) Project Manager and client.
This really is a fairytale story!
It was then time for the developers to descend. They began gnawing away on a prototype on day one. "Finito" they finally declared. So off they trotted to proudly show the client what they were in store for.
Uh-oh, I feel trouble brewing...
"We never liked Platform A, we just wanted to see if we would like it more once we had seen what you had done with it...but no, we still hate it" stated the client matter-of-factly.
"Why is this? We think it suits your requirements down to the ground" quietly demanded the (first) PM.
"We have used it before, I just don't like it, isn't that reason enough?" declared the client, with a stomp of his foot.
The opinion of only one Stakeholder was enough to represent all interests?
The PM huffed and puffed and... was told to go and work in Siberia.
Not quite as dramatic as blowing the house down, but I'm sure it had a similar effect.
The project team were back to square one and without Project Manager, so in his place stepped in the Program Manager.
* Program Manager enters project*
Discussions were being held while the BA's finished off their low level design documentation. It was decided that Platform B would be used instead. Unfortunately I was not privy to these discussions, however, I do think it was no coincidence that this technology was an area that the consulting firm were keen to gain experience on as the lead Technical Architect was Platform B's biggest fan.
Did they push the client into making this Technology Choice or was there a fair analysis?
The project team and developers were then trained in Platform B and unleashed straight onto the client with some difficult questions to answer having not been exposed to the product in a working environment before.
*Expensive Contractors enter fixed price project*
The developers cracked on, the testing team were formed, the UI specification was underway... it all seemed to be back on track.
* (Second) Project Manager enters project*
Relationships were formed, confidence restored and bridges built.
The fairytale ending?
The developers then realised the massive pitfalls of Platform B (in relation to the project requirements, not as a product) and they now had to learn Platform B's bespoke coding language as the customisation needed was so vast. The Project Manager was not impressed with the timelines given, neither was the client.
"Why are we using this product in the first place?" The client repeatedly asked.
Tumbleweed...
The End.
Although this project has had its highs and lows I am pleased to say that it did come together in the end, neither on time nor to budget, but it did come together. Sadly it was without the fairytale ending of another piece of work.
There is no reason to point fingers or hold one person accountable when ultimately projects are a team effort. However, I do think that the team were misled in two respects:
- The bid team had proposed the use of a Technology before fully understanding the requirements of the project
- There was no analysis of other products which then provided the client with a solid reason as to why that product was chosen and which boxes it ticked
Based on my knowledge and experience I feel that it is inappropriate for bids to select a product before requirements are gathered. If I were a client I would be wary of a consultancy second guessing what the best product would be without considering other options and 'seeing their homework'.
There are pros and cons to being partnered with a software house. In one respect you can add benefits to your clients by passing on reduced costs, more well-informed consultants resulting from reduced training costs and access to a wealth of knowledge. On the other hand they may have hidden agendas and feel compelled to sell you said software or have quotas to meet to remain a certain level of Partner.
In a perfect world I would undertake a requirements driven Technology Choice analysis and use the chosen technology to determine the software development house / vendor.
Clients take note: demand a full Technology Choice exercise, it can make or break a project. Analysts, colleagues, friends or competitors may suggest a solution that has worked for them but only a comparison specifically for your project requirements will represent the best choice and deliver real benefits.
Don't forget to leave your comments below.
Emily McCreadie is a London based business analyst working for BSG (Africa)'s London operation. She is interested in evolving methodologies, requirements elicitation and innovation in the workplace.
Comments