Delivering a pizza is easy. Delivering an IT project is not!
Why are they different? If you think about the two, aside from the cheese and crust, they aren't completely different animals. Both have a recipe to follow, both have a customer, both have success criteria, and we have been doing both for a long time.
Case in point, try Googling "IT Project failure" and then "Pizza Delivery Failure". The former will result in hundreds of articles citing reasons/percentages/adages all trying to crack the reasons why, while the latter will show funny YouTube videos of delivery guys falling on the ice. Pizza delivery is just an assumed success.
If this is the case, why is ordering a pizza so much more successful?
Things that make ordering a pizza easy are actually quite elusive during IT project delivery. A US pizza chain, Domino's, does pizza ordering very well. Here is what Dominos presents to the user when a pizza is ordered online.
When you hit the Purchase button after creating your pizza details, you are presented with a screen that gives the customer a great deal of power. It's a quick and easy indication of where your pizza is in the making, baking, and delivering process. Imagine knowing exactly what's happening and when it's happening. As the pizza moves along in its journey from the oven to your mouth, the blue sections turn red and the name of the person responsible for each step is revealed.
What are the benefits of this process to the customer?
- Clear start and end with clear success metrics – I know when my order was placed and I know what needs to be completed to achieve the end result. And I know what my end result is, a pizza!
- Easily understood phases – I don't have how to make the pizza, but I know enough about what each phase represents to feel confident that the pizza is being made correctly.
- Progress easy to measure – Each phase has a clear ending and is unique.
- Easy to know what is next / No surprises – I see what's planned for the pizza and it makes sense; delivery won't suddenly go before baking so there's no chance I get raw dough delivered to my house.
Now, think about the issues with your last IT project. If you are part of the 30% of IT projects that fail, you've ran into these issues and more:
- When is done actually done – I know we've completed the project, but what do I have now that it's complete? Seems like we just did work to do work.
- Project schedule confusion – The project manager sends the schedule every week, but it's 100s of lines long! I don't understand what is being worked on and what is upcoming.
- Are we there yet? – I see from the schedule we are 17% percent complete on the design phase, but what does 17% mean in real life?
- Surprise Surprise – I didn't think we would find so many issues when deploying to production.
IT Project delivery need not be an art form. Instead, it should be a reliable, battle tested, predictable process that is used on every project, no matter the technology or customer.
The standard 1E Project Delivery method is built in such a way to combat common IT project shortfalls. Does this mean all 1E projects are ahead of schedule and under budget? No, but because the 1E project process was created through years of implementation experience, 1E projects are built to have less risk, more predictability, more visibility, and no surprises.
You've heard of the AOR process here. While AOR is the holistic 1E customer engagement model, the Optimize phase itself has a project implementation method born from industry best practices and 1E experience. 1E projects are delivered following this recipe:
Look familiar?
Just like ordering your favorite pizza, customers can understand and track project process in distinguishable and intuitive phases. Upcoming work is predictable.
In the next PMO blog, we'll dive into the specifics of some of these areas and why they are used to combat common IT delivery issues.
