Starting a project requires planning and preparation, and there are countless decisions to make at different steps.
I have defined four step that are quite important, but frequently overlooked, or just handled as an afterthought. These steps by no mean cover the whole of the project, but they are pretty important ones in my opinion. Also the names are not official, it’s just how I call them.
These steps are the following:
- Project decision
- Project vision
- Project planning
- Project outfitting
Before even deciding to start the project there are a couple of things that have to be done.
First of all, when a problem is discovered, the problem should be analysed. Is it really a problem? Or is it just the symptom of a problem?
After discovering the root cause don’t rush to just grab the first solution that occurs. Look at the problem in more detail so you can make an informed, well grounded decision.
The end result doesn’t have to be a polished, over-detailed solution but at least 4 questions should be answered:
Is it possible to solve the problem by training people?
Sometimes all that is needed to correct an issue is to train the people in the correct way to use the tools, or the processes. I know, it doesn’t sounds as exciting as starting a 3 years long project but sometimes it’s the best solution.
Can the problem solved by changing the work procedure?
Sometimes training is not the solution in itself but simply improving the way people work, or the processes can bring in the desired result.
Is the solution changing/customising the current tools?
No need to buy new tools or new softwares, but there is a need to improve the current one. Of course if the tool/software is very old it might be better to get a brand new, modern one. But don’t ignore the possibility if some minor customisation can solve the problem.
Do we need new tools?
And there are times when a completely new tool, software is the only solution.
Of course most of the time you can look at more than one options – changing the process, customising, improving an existing tool and buying a brand new implementation can be possible alternatives for the same problem.
Compare them, pro- and cons, long term effects and goals, ROI and other metrics, whatever makes sense.
And in the end pick one solution.
Don’t rush the decision, it’s better to take a bit more time than to start an unnecessary, 3 years long project because you wanted to make up your mind by the end of the week.
After selecting the solution a detailed concrete definition of the project goal, the Vision has to be created. One of the biggest problems I have seen on projects is the lack of a clear Vision.
Knowing where we go and why is important even on a family vacation, not to mention on a long, multi team project. Although I am sure some parents would say that the latter is a piece of cake compared to a two weeks long family outing with three kids.
The project Vision is relatively stable, small details may change, and of course policy, legal and regulation changes must be followed, but the vision itself never changes radically.
A project with the goal of delivering an Invoicing system won’t morph into a project that aims to implement a mobile phone tracking application.
A clearly defined Project Vision gives a solid foundation for the project, helps to keep it on track.
Change management, and prioritising requirements is immensely easier with a clear vision for the project.
Whenever a new requirement comes in, there is a simple question to answer: Does it take us closer to the vision? How much closer?
If the answer to the first question is no, then you can drop the requirement. If yes, then the second question helps to decide on the importance of the requirement relative to the other ones.
I mean the “how to do” – deciding the way to do project.
What methodology will the project use? How do we customise the methodology for the project’s needs.
Customising the methodology is an important step. I have seen a few RUP and SSADM based projects fail because they were not customised. Ironically the very first step on a project according to both RUP and SSADM is to customise the methodology.
Both methodology recommends a careful review of the available options within the methodology and picking the right ones – no project should include every single role, documentation and technique that can be found in the methodology. Quite the contrary – trim and just use what is really needed.
Select the roles that will be needed. Select the documentations, project phases, techniques that will be used. Come up with the standard templates to be used – even on Agile, it is good to have some agreed on way to conduct the project.
Define the chain of command, the resources needed, and everything else that is necessary to see how the teams will work on the project.
Simply set up the framework and guidelines to follow on the project. It shouldn’t be set in stone, can and will change during the project, but having a good baseline makes life much easier.
When people go on an expedition, they carefully select the equipments they need. Climbing the Himalaya with the wrong equipment is not the safest thing to do.
Similarly, on a project it is quite important to have the right tool – and have them from the moment they are needed.
Decide up front what tools the teams will use for documenting, tracking, developing and communicating.
What hardware they need, servers, test environments, workstations.
Where they will sit, how they will sit. Whiteboards, notecards, markers, chairs, desks, workstations.
It is astonishing how frequently these things are not in place when the project kicks off. When an agile team is spread all over the second floor, and not sitting side by side, when they have to go to the other side of the building to have a whiteboard, it all wastes time. And people won’t be happy.
Same for softwares, switching from Excel to an online agile management tool in the 3rd month of the project, or changing from SVN to GIT halfway through means extra work, and extra risk.
Evidently these issues don’t show up all at once on the same project, but they are prone to pop-up in groups.
If there is no project vision then there is a high chance that the project planning and the project outfitting will be lower quality.
These are not complicated things, and I know that they are pretty common sense. I am certain that when people discuss a project in a calm environment always intend to do them.
Don’t let the “rush to action” sweep you off of your feet, hold out and do these things properly. Skipping these steps will not kill you of course, and if you are lucky, even the project can finish successfully, but it won’t be a fun ride. And why make life harder, if it can be avoided by doing a few simple things?