How to tackle a project start chaos

Are you sure you haven’t forgotten anything before starting up your best grandiose project?

It’s my favorite intimate moment: when everything is planned and decided but hasn’t started to roll yet. It’s a chance to have another prudent look on a plan and get everyone familiar with it.

This article will reveal all the work done before the project starts. The information will come in handy for project managers, team members and all stakeholders who want to make sure nothing was forgotten on stages where mistakes were the cheapest to correct.

The article is designed in a way that you can skip the whole section if you feel you don’t need it. So, go ahead.

I. The importance of preparation magic

II. What exactly needs to be done prior development starts

III. Checklist of all those important things

I. The importance of preparation

Everyone knows that any project should be well planned well in advance. But pre-project work is not limited to planning.

From the moment the genius idea was born or your business has brought out new needs to the day when you set the first issue into “In Progress” state many important things happen. PRINCE2 methodology recalls this part of the journey as Starting up and Initiating a project processes that cover pre-project and initiation stages respectively.

In our days when the word “Agile” hits around every corner, some managers find it challenging to balance between not drowning in “comprehensive documentation” and not ending up with the whole project information being spread in people’s inboxes and text messages (in the best case). Thus the appropriate level of detailed planning has to be considered. Wait, but what is appropriate? Is it the same as eyeballing ingredients while cooking? Not exactly. It might seem tricky a bit but I’m going to untangle it for you.

II. What needs to be done

1. Starting up a project

We all want to start scoping a project as soon as possible. Who is not well familiar with the work breakdown structure and best practices of backlog management? But before that, it’s extremely important to do one more thing — to verify if a project is worthwhile. Could it be any different? You bet! And it’s better to reveal it earlier than after half of the budget is spent.

Now it comes to the good part. Your project board will most likely not give you a green light unless you prove the viability of your concept. Hopefully your inner censor won’t do it either.

So before you dive into development you must find all evidence that your idea is worth becoming a project and worth of funds being allocated. Collect all your proofs in a short Project Brief document to give an overview of project viability. After the project board has given a huge GO to your project you are free to proceed to the next stage — Initiation.

2. Initiating a project

The main idea of the Initiation stage is to answer the question “Which value will the product or service deliver?”

Answering this short question requires a thorough investigation of the user and market needs, client expectations, competitive environment and domain trends. You’ve got to be aware of your team’s capabilities and many other things to make the whole process pleasant and productive. But be careful not to fall into a trap of endless investigation here. PRINCE2 gives a nice structure of this process and suggests a set of documents that will help you to keep a track.

A well-organized project kick-off meeting would be a good platform for collecting crucial pieces of information into a big picture. That information would be accumulated in Project Initiation Documentation. The latter is the basis for all the events happening during a project.

The purpose of kick-off is not just understanding What? Why? and When? It’s also about creating chemistry of having everyone on the same page with a common project vision and a worthy roadmap.

The main outputs of a valuable project kick-off are the following:

• Established project management approach

Here it’s decided on how the project will be executed. The efficiency of using Agile is assessed. PRINCE2 Agile offers a smart tool for that purpose — Agilometer. It’s worth googling at least.

• Requirements

High-level requirements are defined and prioritized. They can be documented in various ways — using dedicated requirement management tools, as a set of items in the product backlog or even as a list on the wall.

• Scope

It’s always a good practice when both team and client have common MVP understanding. If it’s not done before, a kick-off meeting would be a great place to start. The delivery timeline and frequency are also discussed and agreed on.

• Team structure and responsibilities

Which competencies are required to fulfill the project goals? Which roles are needed? Roles can be distributed among team members with one role being assigned to several people and one person executing several roles. The competencies and skills matrix might be handy here.

• Project success

Project success is one of those things that have different meanings for different parties. It’s the integrity of teams and departments’ success that makes the project rock. It’s wise to know ahead what success means and how it will be measured.

• Business Case

Most likely your organization has a standard template for a business case. If not, there are plenty of templates on the internet. Regardless of the way you outline your business case, it’s called to answer the question “Why are we doing this project?”

• Risk management approach

How risks of different levels are going to be handled and where it will be recorded is a minimum that should be specified.

• Quality management approach

Your QA manager will be happy to discuss the strategy for achieving the desired quality level as soon as possible and agree with the team on procedures for managing low quality. This will save a lot of time during the release rush.

• Communication management approach

Noone likes meetings about meetings (except Scandinavians). But it has to be decided in advance how and when communication within the company and inside the team will happen. Which reporting hierarchy does your organization have? What collaboration tools are set as standard or which do you personally prefer? This will help to avoid useless meetings later when everyone is busy with development stuff.

• Change control approach

It’s better to develop a common understanding with customers and stakeholders of what is considered to be a change and how it should be addressed. Once I’ve been a part of a project where neither project manager nor customer knew the difference between change requests and change orders. Do I have to tell you how messy it was?

Other goodies to assess:

• Project management tools
• Daily log (is especially useful when a project involves many parties)
• Definition of Done and Definition of Ready (new or taken from the previous project)
• Sprints length
• etc.

Team and customer engagement are priceless in those discussions. Lessons learned records from other projects is extremely valuable input.

III. Checklist

So, before you roll up your sleeves and proceed to development stages make sure you have the following done (or at least discussed):

• Project Brief
• Project management approach
• Requirements
• Scope
• Team structure and responsibilities
• Project success metrics
• Business Case
• Risk management approach
• Quality management approach
• Communication management approach
• Change control approach

All mentioned above may be represented as a pile of documents or just a short list of decisions.

If you’re the lucky one to facilitate such an event, gather all stakeholders in one room and don’t let them go until a set of decisions is made.

To make this meeting bring value make sure you’re well prepared and so are the meeting attendees. Organize all takeaways in one place, keep them available and updated when needed.

Was that helpful? What are your “must-haves” before starting a project?