HERE ARE SOME REAL CLIENT STORIES
Story I - Can projects be managed without project managers? Would setting a PMO help?
A medium sized company was pretty successful on the IT market. It was creating order management systems for telecom clients in North America and Europe. At the beginning, sales went well, and the Company managed to sell its products to a few leading telecom companies. Next, they had to put in effort to add features for each particular client. To make the core development process more efficient, they introduced the concept of product releases and attempted to create a release management system.
Next, the project management question came in place. Developers were engaged in concurrent implementations for multiple clients. There was no defined process. Project scheduling and cost estimates were done by senior team members and those estimates were failing. In addition, project inter-dependencies were not taken into consideration. Customer satisfaction went down and sales dropped. The service delivery department had challenges meeting their commitments to the existing clients.
That is when our consultant came on board to help the Company establish a PMO in order to come up with the project management processes, to select estimation tools and techniques, to choose the monitoring tools, to setup control mechanisms in order to address product inter-dependencies, and to assist the release manager with release planning so that the end customers would be able to set proper expectations. After a few months, client satisfaction ratios were well up and the team managed to work at a sustainable pace while meeting and exceeding customer expectations.
Story II - Incomplete project scope and false client expectations
A well-established firm won a tender to implement a customer application for a major IPTV provider in Canada. The person who gave the Client the initial estimates left the company, and the team was struggling to meet deadlines that did not look achievable. The Client was not cooperating, which made the situation even more challenging. Our consultant joined the team to investigate the issue.
The first observation was that not all the stakeholders were identified properly, and as such many inputs were missing when the initial time and cost baselines were created. The second problem was that even the incomplete scope would require additional resources and additional skill sets (not available internally) in order to deliver. Last but not least, the estimated milestone dates that were communicated to the client were not achievable.
Here is what we did. Over the first week, we identified the outstanding stakeholders; by interviewing them, we determined the scope gaps. Then, we broke the scope into releases, so that the most important features would be delivered to the Client as Release 1. We set the delivery date for Release 1 one week earlier than the delivery date that was originally promised to the Client for the entire scope delivery. Over the second week, we engaged the additional resources, including the ones with the new skill set. We met with the client and explained that due to the scope growth, we will be delivering more features than originally expected, and we will be delivering them in 2 releases. As such, we introduced the new cost baseline and the new budget.
As a result:
-
The increased budget was approved
-
The scope was identified in full
-
Overall project duration was extended
-
Top product features were delivered to the client a week earlier than originally promised
-
Client relationship was improved
Story III - Engaging a vendor
A customer applications department at a large IT company decided to implement an internal content management system to store its assets – documentation, multimedia files, architecture documents and flow charts. They selected a vendor that had implemented a similar tool for multiple clients across North America. A master agreement was signed with the vendor. The vendor presented the tool and prepared a statement of work. The Client reviewed the statement of work and requested a number of customizations. The vendor claimed that some of the requested features could not be implemented, and requested an extremely high price for other features.
Our consultant got involved and facilitated a few sessions. The first one was with the business department. Project sponsors explained what features were required and provided a feature priority list. The next meeting was with the vendor. Our consultant explored the vendor product and facilitated a gap analysis. Then each particular requirement was reviewed with the vendor.
As a result, the following adjustments were made:
-
The “non-customizable” features were addressed through adjusted requirements that gave the client similar functionality, and were easier to implement for the vendor
-
Some of the features that were in the statement of work were merged with the new requirements for faster implementation
-
It turned out that the vendor was planning a new release with some of the requested features in it, and since the Client agreed to deliver those features as “Phase 2”, the implementation cost was lowered
-
To summarize, our Client received a better content management tool with all the required functionality at a lower cost
THESE WERE JUST A FEW SCENARIOS. BUT THERE ARE CERTAINLY MANY OTHERS. SO WHAT IS YOUR CASE? TELL US.