As a project manager I’ve come to recognize the warning signs of a failing IT project and learned the best methods to get the project back on track. Here are three (of many) things to keep and eye out for and what to do if you find yourself experiencing these common issues…or better yet things to avoid from the beginning. If you are using an Agile methodology such as Scrum in your project, then each of these is addressed by one or more Agile principles and supporting Scrum process.
1. The scope is large and the delivery timeframe long.
There is undoubtedly a strong correlation between the time it takes to deliver a product or service with the satisfaction of the customer. The simple rule is that the longer the delivery timeframe the greater risk the product won’t meet the customer’s needs. Why? Because an organization’s needs change. It’s that simple. Gone are the [waterfall] days where you gather requirements and a year or two later the system is delivered. You are likely getting setup for failure if you are asked to run a project that way.
Solution: Break the project down into smaller parts that are able to be delivered faster (2 months or less)…AND…the deliver the highest priority items first. Don’t forget this very important second part. It does you absolutely no good to focus on the easy or low value items and leave all the important functionality to the end. If the important functionality doesn’t meet the customer’s needs you want to know that as soon as possible.
Agile principle: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
2. Changes in requirements are viewed by IT leadership as the functional stakeholders don’t know what they want.
“Don’t they know what they want, says the IT director.”
“Do those IT folks care at all that this product isn’t what I want, says the functional sponsor.”
Neither of these questions are ones you want to hear, but the reality is that often times changing requirements are seen as a negative rather than an opportunity. We operate in a dynamic environment where the needs the business, as well as technology, change rapidly. Not embracing change puts the organization at a significant disadvantage.
Does embracing change mean you don’t need a rock solid vision for the product and solid requirements? Of course not! It does mean, however, that the development team and senior leadership on both the functional and technical sides should be comfortable with the fact that change happens…and have a plan in place to incorporate those changes into a product backlog.
Solution: First, do #1 above – consistently delivering functionality in short iterations will increase the likelihood the product meets the customer’s needs. Next, practice progressive elaboration and maintain a prioritized product backlog (a prioritized list of functionality) and review it regularly. The backlog does two things: 1) it keeps the Product Owner (business) focused on what is most important; and 2) it keeps the requirements discussions continuous rather than a more time exercise.
Agile principle: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. The end users are not involved.
It’s great that you’ve gotten the organization leadership’s buy-in and their opinion on what the product should and shouldn’t do, but what about the people that are actually going to use it? Are you talking with them? If not, then at some point you will run into an obvious problem and likely get the question “Who wanted this feature” or “why does it work this way?”
Solution: Identify an empowered Product Owner and ensure this person continuously engages the customers and stakeholders to ensure the Team is building the right product. It is critical that the Product Owner takes an active role in understanding the needs of the stakeholders and communicates both the needs and priority to the team.
Agile principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The key to satisfying this principle is knowing WHO your customer actually is!
Delivering on project goals is hard work. It’s hard work for Agile teams and it’s hard work for Waterfall teams. As project managers, Scrum Masters, Product Owners, or team members, it’s critical we keep our eyes open for signs the project is going south. What “warning signs” have you learned? I’d love to hear from you!
July 30, 2014 at 2:49 pm
I would add 2 signs:
– The project sponsor and/or other stakeholders have not-so-hidden agendas.
– The team you have assigned to the project is not coherent and is not getting past the storming stage
By the way, I think this is an excellent post and I would really love to republish it on PM Hut. Please either email me or contact me through the contact us form on the PM Hut site in case you’re OK with this.
July 30, 2014 at 3:04 pm
Completely agree about the 2 you suggest! Working with tough sponsors or other stakeholders and team dynamics increases the complexity of any project…irrespective of the methodology you are using to manage the work – agile, waterfall, etc. When it comes down to it…it’s all about people and relationships. Thanks for the comment!