Part 3: Suggestions to Avoid Similar Situations
Stakeholders may exert influence over the project and its results – PMBOK.
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.
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.
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.
Project resources should be expended ... where a lack of communication can
lead to failure- PMBOK.
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".
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".
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.
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.
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."
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.
8. A Guide to the Project Management Body of Knowledge
(PMBOK® Guide) 2000 Edition, Project Management Institute, PA, 2000
11. Mullen, R.,Taking Customer Relations to the Next Level The
Journal of Business Strategy, January – February 1997
12. BA Shake-up, "Not due to new scheme", Travel Trade
Gazette UK & Ireland, May 7, 2001
13. A Guide to the Project Management Body of Knowledge (PMBOK®
Guide) 2000 Edition, Project Management Institute, PA, 2000
14. Bullock, James, lead editor of the Roundtable on Project Management
from Dorset House (http://www.dorsethouse.com/),
based on D. Phillips "The Software Project Manager's Handbook"