I was presenting some research recently showing how badly most IT projects do. Did you know that a government audit reckons 50% of UK Government IT project fail or that Mckinsey estimates 80% of global IT projects don't succeed? During the presentation someone asked me to define failure. I reeled off my usual theoretical answer about judging a project against its time, cost, quality, scope, and business objectives, but later I started thinking how difficult it is to tell how successful a project really has been.
One of the first large projects I managed was a UK government web site. We delivered all the initially requested features on time and to budget. On the launch day we went to a restaurant to celebrate and as I took a seat next to the client I remember feeling pretty pleased with myself. That feeling didn't last long! When I started to talk with her it quickly became clear she wasn't happy.
She was frustrated. A few weeks before launch her team had realized they wanted some other things added to the initial requirements. Our change control process had prevented them from adding these items. I tried to explain to her that this would have significantly delayed things, and how important hitting the deadline had been, but it didn't help her mood.
This experience taught me that sometimes you can hit all the initial objectives, so in theory your project is a success, but still have an unhappy client. It also taught me that it is very difficult for clients to outline their requirements at the beginning of a project. It is often only when they start seeing what we are creating for them do they start to realize what is possible and what would be useful. Because of this if we measure our success on delivering to the initial set of requirements, the project might appear successful to us but our clients may be disappointed. What we really need to do is work with them in the initial stages, maybe using approaches like prototyping, to help them understand what is possible and what is really needed. Only when we are sure they really understand their wants and needs should we judge ourselves against delivering to them.
[sidebar_cta header="Preparing for PMP Certification? Gain Key Insights on PMBOK(r) Guide 6th Edition and More." color="blue" icon="" btn_href="https://www.learningtree.com/resources-library/webinars/what-the-new-pmbok-6-says-about-the-best-way-to-manage-complex-projects/" btn_href_en="https://www.learningtree.com/resources-library/webinars/what-the-new-pmbok-6-says-about-the-best-way-to-manage-complex-projects/" btn_href_ca="https://www.learningtree.ca/resources-library/webinars/what-the-new-pmbok-6-says-about-the-best-way-to-manage-complex-projects/" btn_href_uk="https://www.learningtree.co.uk/resources-library/webinars/what-the-new-pmbok-6-says-about-the-best-way-to-manage-complex-projects/" btn_href_se="https://www.learningtree.se/kunskapsbank/webinars/what-the-new-pmbok-6-says-about-the-best-way-to-manage-complex-projects/" btn_text="Watch On-Demand Webinar"]
Another area where you can theoretically succeed but still disappoint clients is quality management. In many project management approaches quality is defined as meeting user's needs or creating products that are fit for purpose. But is a successful project one where we have just "met needs"? Would Apple be satisfied with delivering an iPhone which only was fit for purpose? I think not! Their target is to go much further than this; to delight customers, to exceed expectations and create step change functionality. If we deliver products which meet expectations, theoretically we might have a successful project, but, in this time of ever increasing expectations, our client might be disappointed.
So I think that there are no hard and fast rules about what makes a project a success, it's all about subjective perceptions. This means it is very important to build a relationship with our clients throughout the project so we can really understand how they perceive the service we are delivering to them.