Project readiness checklist

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:

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 colorful PowerPoint presentation that people can talk about at length without addressing any real architectural concerns.

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, which means that critical qualities in the design will be overlooked and the feature might not fit actual needs well.

Project environment established and well-functioning

Already while shaping the solution proposal it’s helpful to have a well-functioning project environment where draft work products like project plans and architecture documents can be shared with stakeholders.

It seems obvious, but almost all projects I’ve ever worked in have struggled with this, wasted countless work hours and caused enormous frustration in the project team and among stakeholders.

So how does it go wrong? Well, normally there’s just a fileserver where the project manager starts creating a folder structure to hold the initial work products and filed gathered during idea development. Or maybe SharePoint is used in this same manner.

As more people join the team and more and more work products are created, more and more folders, and links to files are spread via Teams chats, emails, meeting invitations and embedded in documents and spreadsheets.

Soon it’s almost impossible to find anything. There’s no document inventory, no standard folder structure and no search features. People start trawling old mails and chats to scavenge for links to files that has sunk under the surface.

And the next problem is that when the team starts sharing links to documents, they get bombarded with requests to be given access to actually open the files. Or people just hurry along with other work, not even having or taking the time to request access. Similarly, when inviting people from other organizations to contribute to creating work products, access is again a struggle.

To minimize this hassle, establish a cloud-based integrated content and task management. Ask your infrastructure people to help, and have them secure access to protect your information.

My preferred project environment is Atlassian Confluence for writing and sharing work products, and Atlassian Jira for managing tasks and bugs. There are alternatives, but Atlassian allows you to open a free account that helps you master the two tools and even use them for smaller teams with up to 10 members.

Project administration organized and well-functioning

Project administration deals with seemingly mundane things like making templates and work products easily available to everyone involved in the project work. Also, helping onboard new team members and stakeholders are administrative tasks, as is coordinating with infrastructure and operations people to establish and maintain the project environment.

While a poorly functioning project administration may the be the one missed readiness criteria that sinks the project, it causes a lot of friction and dissatisfaction in the team, and may also be noticed by stakeholders outside the team, giving the impression of weak project management.

Establish a well-functioning project administration early on, and your team will save time on reoccurring tasks like starting new work products (finding the right template and any corresponding guidelines quickly), contacting the right people (easily finding their contact information), and lots of other chores that will go faster with the support from the project administration.

Meeting and communication practices defined, sanctioned and understood

The process of developing a solution requires collaboration of stakeholders and team members within various disciplines. This in turn requires a lot of communication.

Communication happens in corridors and by the coffee machines, in online and physical meetings, by email, through links to shared files and by passing copies of files around in emails, in intranet webpages and in phone calls.

The communication practices are often part of the organization’s culture, and projects that involve multiple organizations are exposed to multiple colliding cultures.

Meet less

Meetings should only be held between very few participants to co-create and refine actual work products that drive the ongoing development forward.

Discussions should be based on already or not yet started work products, and decisions should be reflected as new and updated content in work products – not as meeting minutes or issue logs.

Not leaning on a proven development process easily leads to too many meetings in which too many participants discuss concerns without concluding anything except that yet more meetings are necessary with even more or different participants.

Meet online

Online meetings over for example Teams makes it easier to gather the right participants – you don’t need to wait for everyone to be physically present at the same time. Also, participants are more likely to be on time because they don’t have to walk from room to room, perhaps even at different floors in large office buildings. And people can sometime discretely eat lunch while in an online meeting.

Some people obsess about only meeting physically so they generate even more communication by constantly asking others if and when they’re in the office and postpone important discussions until a meeting can be arranged in the office.

With proper facilitation almost every discussion can just as easily take place online and can therefore often take place much sooner – especially when physical meetings rooms also have to be available at the same time as every meeting participant.

In physical meeting someone often draw on a whiteboard, which has to be photographed using a phone camera. Then photos have emailed to a safe email account, and downloaded to a shared location – but the photos start their life outside secure boundaries.

Meet about work products

Only meet to co-create and refine work products that are prescribed by the chosen proces – everything else is a waste of everyone’s time.

Clearly state in the invitation which work product(s) will be worked on, and insert links to the work products.

Keep meetings short

Much can be achieved in 25 – 45 minutes if the meeting is properly facilitated.

Start meetings on time

If people aren’t bogged down in end-to-end meetings every day of the week, chances are they can actually be on time. Meeting online also increases the change people join on time. And end meetings 5 – 10 minutes before the next wave hits.

Starting on time often requires the organizer starting ahead of time to set up video conferencing equipment, clear any booked rooms, bring writing materials etc. For online meetings the organizer will benefit from opening relevant work products to be ready to quickly share them on-screen during the session.

End meetings when done

One of the worst malpractices is to book one-hour long meetings, realizing that the objective has been achieve 45 minutes in and THEN starting to ask around if there’s something else that should be discussed! NO! End the meeting as soon as the objective is achieved and give people the remaining time to do something more productive.

Don’t Email

Don’t use email for communication about the ongoing development – use whatever task management tool you have set up, for example Jira.