Regardless of the project methodology used, there are a few things which, if present, will significantly reduce the risk of project failure. I am sure there are others, but this is my top ten list:

10—Project team that includes all stakeholder groups

Every team or department that will be affected by the project needs to be represented on the team. This includes: developers, testers, infrastructure, database, application risk management, application security, enterprise services, etc…

The team needs to be enabled to make decisions regarding how the application does what is defined by the requirements. If it is not possible to have one or more groups represented on the team, then the business owner needs to have the authority to prioritize the time of those groups missing from the team to make them available when they are needed.

9—A sense of ownership among all members of the project team

When everyone is acting in concert as a true team, project risk is greatly reduced. The often present herding-of-cats done by project managers is counterproductive. The solution to many project problems require coordination among several people, often from different functional groups.

For instance, to make a service available from the Internet, the application development team may need to add code to implement role-based-security, the application server owner may need to install a certificate, and the infrastructure team may need to open some ports on the firewall. If each team feels a sense of ownership for the problem, they will all work together until everything is working. If team members only care about getting their part done, solving problems that touch more than one area of expertise is much more difficult.

8—Make final decisions as late as possible, but no later

Making decisions late mean making decisions with as much information as possible. Late decisions shouldn’t be confused with analysis paralysis. Late decision-making is an active process of deciding when a decision is actually needed. Late decision-making is a key tenet of Agile development.

7—Skill sets of team members are sufficient

It is imperative for project teams to be staffed with people skilled and experienced enough to complete the project and product tasks. This is not to say that you can’t have any inexperience people on the team; it just means you should have enough experienced people to help and coach the inexperienced people.

6— Sufficient funding to complete the project tasks

If your project is a Waterfall project, or some mixture of Agile and Waterfall that includes a fixed scope, then sufficient funding means a budget large enough to cover all planned tasks, plus a contingency and management reserve. The contingency reserve is an amount of budget set aside for unexpected costs and is controlled by the Project Manager. It is used to cover expenses that are known to exist, but whose dollar amount are unknown or end up being greater than expected. These are sometimes called known-unknowns.

The management reserve is set aside for unexpected expenses and is managed by management. This account would pay for unplanned expenses, sometimes called unknown-unknowns.

If your project is a true Agile project, with a defined team and schedule, and variable scope, then sufficient funding means being 80% confident the available budget is large enough to cover the team for enough sprints to complete all of the features that are required. This is a much more fluid definition than for a Waterfall project because Agile is designed to be, well, agile.

5—Sufficient time in schedule to complete project tasks

In practice, time constraints are almost always artificial—or at least this is how it seems. A product manager or executive picks a date that sounds reasonable and that date becomes the due date. Or a sales person sells a solution with a due date promised in the contract. Rarely do project due dates get set by the project manager after doing a complete bottom-up task analysis.

As with funding, in a true agile project, schedule is not pre-defined and, therefore, not as critical as it is for a waterfall project. However, it is still imperative for the team to be given enough iterations to complete the required functionality.

4—Prioritize features based upon business value

Define the show-stopper items and tackle them first. The last thing you want to do is to create 80% of your application, only to find out there is no way to accomplish the one, most important feature. Once you have created all of the features that, if missing, would make the application worthless, continue to work on the remaining items in order of their value to the business.

I like to sort these remaining requirements by an index created by dividing the business value by the estimated cost. This sorting pulls the higher value, easiest to build items to the top of the list and pushes the lower value, harder-to-build things to the end. Another, slightly more complex option, is to use the formula SAFe suggests for the WSJF calculation. (See my previous article for more information.)

3—Testing that is automated, continuous, and sufficient

Testing must be automated, as much as is appropriate; must be done continuously throughout the development process; and must be sufficient enough to assure the code meets the requirements. This continuous testing should not be limited to unit testing; it should also include functional, user experience, integration, performance, security, and governance.

2—User stories or requirements that include the definition-of-done

The definition-of-done should be included in every requirement or user story. It is unfair to the developers to call something a bug if there is no definition-of-done, or if it passes the definition-of-done that is documented in the requirements. If something is determined to be not correct during post-development testing, but it doesn’t fail the definition-of-done, then it is a change in the requirements, not a bug. The team should be empowered to refuse to develop any code for any requirement for which they do not have a clear understanding of the criteria which will be used to judge their work.

The level of detail in the definition-of-done will determine the amount of freedom the team has in meeting the requirements. If the team is trusted, without reservation, to create a working solution, then the requirements can be less precise. However, it also means the team will flesh-out the definition-of-done for themselves, and their definition may not match the business’ needs. The definition-of-done should be precise enough to assure the business process will work correctly and efficiently, without hog-tying the team too much, and preventing them from using the design skills for which they were hired.

1—Active involvement by the business owner

And, the number one factor in project success is active involvement by the business owner. The business owner, who is preferably available on a full-time basis, has been assigned to the project to represent the business needs of the organization. This would be the Product Owner in Scrum, or the Key Stakeholder in Waterfall.

This person needs to be empowered to make decisions regarding what the application does. In other words, they own the requirements. They are responsible for delivering the requirements to the team on a timely basis, and clarifying any questions the team has regarding the requirements. In addition, they need the budgetary and staffing authority necessary to complete the project.

Conclusion

Of course it is unrealistic to expect to have all ten of these on every project, but a guy can dream. The bottom line is that none of these items is required for a successful project, but each of them will reduce the risk to the project; and managing risk is everyone’s responsibility.

See you next time…