Introduction | The Project | Project Management Processes | Progress
Things Start to Go Wrong | Workshop Outcome | Next Steps | What Went Wrong?
The Purchase Process and Buyer's Remorse | Suggestions to Avoid Similar Situations
Commentary | Issues for Discussion

Part 3: Suggestions to Avoid Similar Situations

Scope Management
Stakeholders may exert influence over the project and its results – PMBOK.[8]

The business case document was shown to a number of the Client's representatives from senior management to the users. With hindsight, it was clear that the key decision makers were the Client Project Manager and the User Technology Consultant (see Figure 2 above). Unfortunately, they were not singled out to make sure that they understood the benefits of the upgrade. This meant that they accepted the project's goals in principle but decided to wait to see what it delivered before they would give their approval.

Lesson learned - Key stakeholders/decision makers must be identified.

Quality Management
A quality audit is a structured review to identify lessons learned that could improve performance of the project. Quality audits may be scheduled or random, and they may be carried out by properly trained in-house auditors or by third parties, such as quality registration agencies. - PMBOK.[9]

The User Technology Consultant approved all the specifications and the project team thought that everything was on track. He obviously had reservations that he shared with the Client Project Manager but not with the project team. SP Management conducted a project review, effectively a project audit, but "the Client did not comment on the product that was being produced" (see above).

Evidently, the reviewer did not ask the correct questions. The team of outside consultants found out what he was really thinking and the workshop provided a forum to share this information with everyone.

Lesson learned - Carefully designed quality audits should be conducted at regular intervals.

Communications Management
Project resources should be expended ... where a lack of communication can lead to failure- PMBOK.[10]

The SP sales department made the incorrect assumption that, after the sale was made, it could ignore the Client. It is fitting to refer to how Hewlett-Packard's (HP) marketing division has developed a concept called "trusted advisor".[11] The marketers felt HP needed to move beyond selling systems to selling itself as an advisor and had to offer customers specific solutions to unique problems. What HP discovered is that some customers want a partner and others simply want a product that works. HP assumes an advisory role when it sells complex products. British Airways similarly identified a need in the corporate market and added "key account" managers to "focus on accounts that delivered the most value".[12]

In this project the SP did not have someone playing the part of "trusted advisor to the Client". It should have assigned a senior account support type of person. Making calls to see how things were going, informal visits, and lunch with the Client. Software implementations are fraught with challenges and often, incorrect perceptions are created, that need to be addressed. The Client looked for a trusted advisor to whom it could turn to at the SP. It appears that such a person was not available so the Client looked elsewhere.

On the other hand the User Project Manager did not share his true feelings with the project team until he was in a very public forum. That made it extremely difficult for the SP to manage the situation. What was clearly missing was communication at different levels and especially with an account executive/sales support person.

Lesson learned - Informal communication and interaction at different levels is vital.

Risk Management
Taking early action to reduce a risk's impact on the project is more effective than trying to repair the consequences after it has occurred - PMBOK.[13]

James Bullock has been building systems professionally for 20 years. He has the following to say about software development projects:

"The biggest difference between software and the products of other kinds of projects is that it is not physical. Software consists of ideas, designs, instructions and formula. Creating software is almost entirely a cognitive activity. Software only matters when it appears as something real, even as barely real as colored squiggles on a computer screen."

"Maintaining that connection from "thought stuff" to "real stuff" is one of software's peculiar challenges. The artifacts in software projects often aren't as visible or well understood as in other projects. Since you can't kick a chunk of software like a brick, you have to create ways to see that it's there. Tracking progress is often the hardest thing in software."[14]

The SP incorrectly assumed that once the Client signed off on the scope document, there was no risk of the final product being rejected.

Lesson learned - For software development projects especially, there is the risk that the product will not meet the Client's practical expectations and will be rejected.

The Purchase Process and Buyer's Remorse

Commentary

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page