Over the years countless projects have failed to deliver on time and on budget, and while there may in rare cases be truly unforeseeable and extraordinary events to blame, most projects fail because they never reach a reasonable level of readiness to run.
This lack of readiness to run a project is comparable to attempting to run in waste-high water. Everyone struggles to gain momentum but the speed never picks up and sooner or later everyone collapses from exhaustion. If the project eventually delivers, its deliveries are over budget, late and possibly already outdated, and of poor quality, which further undermines the feasibility of the investment.
I recommend that anyone considering starting a project first determines to which extent the project readiness criteria are met:
- Costs estimated and covered
- Actionable project mission statement defined, sanctioned and understood
- Enterprise architecture known and understood
- Development process defined, sanctioned and understood
- Team covering relevant disciplines formed, allocated and committed
- Project environment established and well-functioning
- Project administration organized and well-functioning
- Meeting and communication practices defined, sanctioned and understood
- Stakeholders identified, engaged, briefed, allocated and committed
- Risks identified, accepted, analyzed and addressed
- Targeted business processes identified and understood
- Planned business processes identified, defined, communicated, sanctioned and understood
- Information model defined, communicated, sanctioned and understood
- Data management defined, communicated, sanctioned and understood
- Available infrastructure known and understood
- Operations organization and deployment processes known and understood
- Surrounding application landscape known and understood
- Required system integrations identified, analyzed, negotiated, defined, communicated and understood
- Requirements identified, defined, communicated, sanctioned and understood
- Architecture defined, communicated, sanctioned and understood
- Releases defined, communicated, sanctioned and understood
- Go-live plans defined, communicated, sanctioned and rehearsed
- Releases accepted by and handed over to operations and support
- Solution accepted by and handed over to maintenance
A good project plan reflects the project’s readiness using these criteria. Throughout the project’s lifetime it’s important to constantly monitor the project’s continued readiness to complete its task as conditions change.
Costs estimated and covered
Having sufficient funds to see a task through is obviously necessary to complete it. However, whether such funds are then allocated to the task is rarely transparent. Managers will happily ask you to look into something without bothering to secure funds and other support to help you succeed.
If you’re asked to prepare a project proposal, you’ll need to spend a number of hours researching, writing drafts, and talking to others – and they will often ask where you register their time spent talking to you. So ensure that you get help allocating a reasonable amount of hours for yourself and others, and that you have time registration details readily available when asked – and for your own use.
In an ongoing project it continues to be a prerequisite for collaborating with colleagues outside the project team to have time registration details readily available.
Projects also need to ensure funding for remaining work. Even the rare project that manages to stay on budget risks budget cuts – the risk is higher the longer the project runs.
Threatening budget cuts or budget overruns must be treated as risks. Insufficient funds must be handled as a problem.
The risk – and subsequent problem – is that the benefits driving the investment will never materialize to balance out the costs. Only a loss will remain, even though some knowledge may have been gained, which could be useful in the future.
Also, costs don’t just stop abruptly. It takes time to dismantle the project organization and project environment, which means some more time spent – meaning continued costs until all activity finally stops.
Actionable project mission statement defined, sanctioned and understood
To achieve any goals it’s helpful to know what’s expected – it’s also helpful when determining which resources to request and how to utilize them appropriately to delivery the expected results on time and budget.
Already when you’re asked to develop a solution propsal or starting a development project, prioritize agreeing with your bosses on a clear definition of your goals. Refuse to run with a fuzzy directive; demand an actionable mission statement, and restate it in your project plan – and update it if and when your directives change.
To be actionable, a mission statement must of course be clear on the objective, but also promise appropriate funding and resource allocation.
Throughout the course of the project things happen that give cause to revisiting your mission statement.
Costs may exceed expectations and risk budget overrun, or previously promised funds may get withdrawn. If this happens it’s unlikely to make sense to think that the mission statement can be said to still be actionable. The goals need to be adjusted to the new reality.
The targeted business areas may see drastic changes in the market that should lead to scope adjustments, which in turn may have to be well reflected in an updated mission statement.
Enterprise architecture known and understood
While researching and forming an idea for a project, and subsequently while running the project, there’s always a surrounding enterprise architecture in which the project’s outcome will be immersed.
Unfortunately, very few organizations have a well-managed and well-documented enterprise architecture. It’s there, but it’s fuzzy and ungoverned. This means that there’s no help to the project when it comes to identifying which processes will be impacted by the project’s deliveries, no useful overview of the infrastructure and application landscape, no efficient development process to follow and no guidance on how to effective implement the solution and hand over any developed software to operations for support and maintenance.
Instead, the project must establish its own understanding of the enterprise architecture, a task that might well make a significant dent in the project’s budget and delivery schedule. And since it’s rarely a task that’s acknowledged as necessary by management and sponsors, the project isn’t likely to have the necessary expertise covered in the team, which means that the established understanding of the unmanaged enterprise architecture is inaccurate.
Ideally, the organization’s enterprise architecture is well-managed and well-communicated, making it known and understood by the project team.
This gives the project the best possible starting point for meeting almost all the remaining readiness criteria in this checklist.
Development process defined, sanctioned and understood
A development process standardizes disciplines and work products, which increases precision and expediency. This in turn helps achieve the project’s goals on budget and on schedule.
Without a development process people will either not produce any useful work products at all or their work will be of little practical use by others in the same project.
Be careful not to think that Scrum or SAFe are development processes! They are frameworks for organizing and managing maintenance and development across projects and departments, but they don’t offer any method guidance for disciplines required to develop solution.
Some organizations have a development process that only covers some disciplines, which isn’t of much use since one of the benefits of creating work products is that they serve as valuable input to subsequent work in other disciplines.
Defined development processes aren’t always followed by everyone, which also also decreases its usefulness.
If a project is faced with having to define its own development process, it’ll waste valuable resources and time doing so, and will also struggle with convincing others outside the project accepting the defined development process.
Team covering relevant disciplines formed, allocated and committed
To develop an idea to a viable solution proposal, and to run a development project to build and implement the solution, requires a collaborative effort from various disciplines.
If you, or your project team as a whole, lack expertise in any of the necessary disciplines, progress will be much slower as people attempt to reinvent the wheel as they go and work products will be poorer.
In many organizations idea development and developing solution proposals are left to project managers or department managers – sometimes with part-time assistance from someone with the job title business analyst but who’s not really trained in the discipline.
That’s why most solution proposals take the form of a PowerPoint presentation with relatively random content – but in colors and incomprehensible text. And when the project starts, developers are recruited into the team and building starts. Too often with no attention to architecture or understanding of how it will service the business.