When You Do Not Decide, You Have Decided
“Yet another request for a change in the specifications of the application,” said Pierre, my project manager.
My company won the bid to develop new insurance software for this Canadian company on the basis of a comprehensive request for proposal (RFP), which included a detailed functional requirements list.
Sandy, the client’s project director, kept changing these original requirements, adding additional functionalities during our weekly project status reviews. Every change request needed to be reviewed and approved by my project manager and myself.
If the change requirement was not part of the original RFP and included in our bid, a time and cost estimate needed to be done at the expense of the client, and added to the project in the form of a formal change request. The change request approval process included details like change development effort mostly in terms of in person-days (which could increase or decrease), and other related expenses such as the resulting implications—mostly additional costs and deadline changes. This was the standard procedure as specified in our proposal and accepted by the client organization.
However, the client’s project director argued that all her change requests were part of the original proposal; therefore, they were supposed to be included in the initial bid price. The only leeway we had was adjusting the timeline to accommodate the requested changes.
During the first few weeks of the project, the project manager tried to respond to those change requests by negotiating a compromise on the functionalities and time extensions involved. After these first concessions, Sandy’s change requests became more extensive, obviously outside the project’s original scope. She refused any negotiation or concession.
A few weeks later, I had no choice but to terminate my company’s involvement in this project and absorb the resulting loss.
My competition was quite eager to fill-in the gap.
I read in the newspapers two years later that my competition also withdrew from the project after incurring a multimillion dollar loss.
I withdrew in time.
Constructive change management is essential for every project.
Unfortunately, software development projects have a tendency to result in cost overruns and missed deadlines.12
Because software functionality is often difficult to describe precisely before it is fully functional, but easy to change after it has been developed, a piece of custom software that fails to deliver on its objectives may sometimes be modified over time in such a way that it later succeeds. Furthermore, business processes or end-user mindsets may change to accommodate the software. However, sometimes, for various reasons, neither approach succeeds or is even tried, resulting in failure.
“All is fine.” Richard would always start the biweekly project review meeting with these words. He considered himself a “doer” not a “talker.” Therefore, meetings were only infringing on his time. He had more important things to do than to present the status of his project to the chief operating officer, especially in the presence of his team leaders.
This was the most important project my company had presently. The company won a two-year contract to build from scratch a top-of-the-line pilot boat that will be used by the local pilotage authority. The bidding process was demanding. Competition was fierce. However, by securing Richard as the project manager for this job, the company had an advantage over the competition. Richard had a good reputation in the industry. He was known as somebody who not only knew the ship-building business, but also delivered on time and on budget. The client had confidence that the project was in good hands.
Until now.
I was following the project financials very carefully. We had an agreement to be paid as each project phase was achieved; therefore, revenues were directly depending on meeting deadlines and delivering the agreed upon finished goods at each stage.
Following project specifics was not my forte—it was Richard’s responsibility. I relied on his reports to bill the client. On the other hand, the client had specialized resources reviewing each production stage to ensure the company met quality standards and deadline targets. Their findings did not concord with Richard’s. Something was amiss. What was it?
I needed to investigate the situation in more detail with the assistance of our accounting department and some of the team leaders. Furthermore, I also hired an outside auditor to review the project status. His report confirmed everyone’s suspicions. We discovered that Richard had a major weakness: he could not keep the project scope in control. Changes continuously occurred without proper follow-up, documentation, or even justification. Just because someone (this could come from the client, the supplier, or the workforce) wanted to implement a change, the change was accepted without questioning it.
This form of weakness in project management resulted in project delays, cost overruns, and frustration of the project team leaders. Their individual deadlines could not be met either. Consequently, their bonuses would suffer. The overall project deadline might not be met. Associated penalties to the company would incur. The whole catastrophe was looming on the horizon.
I had no option but to relieve Richard from his duties as project manager. We found a couple of industry specialist who split Richard’s functions and rescued the project from potential failure. One year later, the vessel was delivered on the last day of the project’s extended deadline date.
It was in the nick of time.
Check, and then check again.