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

Issues for Discussion

1. In this project the Client was never specific about what he did not like about the software package he had agreed to. He came to believe that there were other packages available that could do more. Unfortunately, the Client did not make his position known before the project started or at least near the beginning. This suggests either insufficient homework by the client before the project was initiated, or insufficient work between the SP and its Client in a conceptual phase of the project.
   
   As a consequence the client started to react to seemingly small things that became an issue that could not be solved. Often it is the cost or time taken that is of concern. Or possibly functionality that was never an issue but suddenly becomes a showstopper. However, in this project there appeared to be none of this. The relationship always remained pleasant, no major issues or objections were raised, everything was signed off as requested and invoices were paid on time.
   
   Rather, trouble was obviously brewing and it came out in a very indirect way that made it difficult for the project team to identify sooner.
    
2. Regular quality audits could have been conducted to make sure that everything was on track. Most important, of course, is to acknowledge that there is a risk that the Client may not see a benefit in what is being done. There is also a joint responsibility between the buyer and the seller to make sure that the sale is successful. The Client should do some research in the market rather than accepting, at face value, what a sales person has on offer. If the Client does not do any homework, then 'buyer's remorse' may become an issue at some stage. This should be added to the list of risks and the project team should have a mitigation plan. In this project the Client and the SP were both working towards the same goal. The only problem was that they eventually ended up in different fields.
    
3. There were a number of unanswered questions as to what the Client Project Manager and the User Technical Consultant were really thinking. Were they tired of the SP and just wanted a change but were unable to persuade the managing director? Instead they therefore allowed the project to proceed, hoping it would fail? Were they bored with the project – perhaps it was going on for too long? Did they deliberately try to deceive the SP? Did they have a hidden agenda from the start? Did they feel threatened, as perhaps the new system might have made their positions redundant?
    
4. Were the benefits of the project properly identified and if so were they optimized? Were the outside consultants as blameless as they seemed to be? Or did they have a vested interest in the outcome and so took the opportunity to "broadside" the SP?
    
5. Could all of this have been avoided? The most obvious suggestion is to identify the key decision makers in the Client's office. Once this is done, an effort can be made to ensure that this person/group accepts fully what the project is setting out to produce. They can also be made the subject of special communication from the SP account manager/post-sales person.
   
   This is typical of the danger when more than one person represents the project's "sponsor" and the most influential representative is not correctly identified or perhaps even present.

Commentary

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