I just finished a week of hard work and long hours. I want to share the experience with you because it clearly shows how stopping and planning can help you.

The task

We had to prepare a proposal for  a complex system.  The competition was expected to be high, so our proposal had to be high quality.  We have been working on the concept for this system for a long time, so we had a clear view of what the system should look like.

The challenge

We only had 3 weeks to prepare everything.  We had to discuss the solution with several areas in our company and with a subcontractor.  By the time we had everything agreed, we only had less than two weeks to produce the documentation.  The amount of required documents was larger than we expected, which made things even more difficult.

The plan

We knew all the documents we had to prepare and the clock was ticking.  So what does your body do?  It forces you into action!  For a second we were tempted to start working, because we knew already what we had to do.  But did we really?  We had a mental list of the documents and a preliminary distribution between the (at that time) 2 persons working on the proposal.  But we realized that wasn’t enough.  So we stopped, wrote all the documents on a whiteboard and made an estimation of how long it would take to finish each of them.  The result was shocking.  If our estimation was correct, we had to work over 16 hours a day to meet the deadline!!

Thanks to this 10 minute planning, we had the arguments to convince our boss to give us another person to work full time on the bid and distribute some tasks among other people in the department.

The execution

One of my colleagues had the idea to keep the list of documents on the whiteboard and write the progress at least twice a day to monitor if we were on track.  I have to say that it was a great idea, and not for the progress monitoring, that we could have done in a different manner.  But it was for the motivation.  Every time someone stood up and increased one of the percentages we had a rush of excitement and we knew we were making progress.  And whenever someone felt overwhelmed, we could look up at the whiteboard, check the status and see what the objective progress was.  And most of the times the situation was better than what our mind told us, especially when we were tired.

The conclusion

Even when you know that you should plan, it’s easy to rush into action without much thought.  And we should avoid it.  See what 10 minutes did for us.  Hadn’t we stopped then, we wouldn’t have had the extra help and our technical proposal would have been poor.

And this shows that planning is helpful for every task we have to do.  Some people tend to think that only project managers should plan and monitor progress.  But the truth is, if you plan your everyday tasks you become much more productive because you manage your time instead of spending it.

So, every time you feel overwhelmed by all the work you have to do, please don’t just jump into action.  Stop and plan first.

This is another lesson I learnt the hard way.  Being new to project management, I decided to copy what other project managers were doing around me.  At that time, the general trend was to give our Customer the least information that was necessary for each milestone.  In fact, that is not completely true.  We were usually rushing to get the documentation for development milestones, so the immediate solution was to reduce the quantity and quality of the information provided.  Back then it didn’t look that bad… The customer is happy because we are on time and we reduce development time because we don’t have to produce as much documentation.

We were quite wrong!  We didn’t have our design documentation ready not because we didn’t have time to write it down, but because we hadn’t analysed our design thoroughly.  And having a design review without a clear idea of your design is a bad idea! Our customer didn’t review our documentation in depth so they didn’t object to the level of detail.  So we passed the review, which lead to the disaster, because we started working in a direction that was different to what our customer expected.  The result was similar to working without planning.

So the lesson we learnt was clear:

• Identify your stakeholders
• Find out what they expect
• Manage the misalignments between stakeholders’ expectations and project scope or goals

Expectations management is a continuous job.  The Project Manager has to know the direction of his project and communicate it to all the stakeholders.  There will be moments where expectations are much bigger than what we plan to deliver, and it is highly important to address this issues as soon as possible and find an agreement.  Otherwise, what we would do is postpone a problem to the end of the project, when there is no reaction time.

“I can’t afford to stop to plan.  We have to start working if we want to meet the deadline”

How many times have you heard this?  I still shiver every time I hear it, and I hear it much more often that I would like.

It must be something innate to think that you have to start doing something when you feel you don’t have enough time to finish a task or project.  But hey, planning is actually doing something!  But then someone argues that you can finish your project without planning, so if you don’t plan, you save some time and finish earlier.  (Deep breath…)  OK, you start working right away but, in which direction?  Do you even know what you have to do?  Have you defined the scope of your project?

I have seen (and I am afraid I will see) too many people rushing into action to save time, to discover later that they have worked in a wrong direction.  And when you get to that point it is usually too late to get the project delivered on time.  A lot of people don’t realise how important a good planning is.  It helps you discover the dependencies between tasks and find out what the critical path is.  And knowing that allows you to focus all your effort on the tasks that drive the delivery date.

So no matter how tempted you are to start working without a plan, please stop and plan your work.  It will pay off!

It might seem quite obvious, but can you answer the following question:

What is the scope of the project?  Or in other words, what do you need to produce to consider the project successfully finished?

I am sure you would at least be able to give an answer like “We have to develop (or upgrade, manufacture…)  a system (or component, SW program…) that has a defined functionality”.  And you might even be able to define this functionality as a set of requirements.  This is good, but it is far from complete.

Imagine two different projects.  Both have to deliver the same product with the same functionality.  Project A was contracted as a development project, and therefore the customer will ask for detailed requirements documents, design documents, blueprints and so on.  Project B was contracted as a COTS, and the customer is only expecting user level documentation, like user manuals or maintenance manuals.  Is the scope the same in both projects?  Not at all.  Project A will have to produce a lot more documents before considering it finished.

And the difference between two scopes could be subtler.  Only a change in the Quality standards or the Qualification methods could make a substantial difference in the workload required to finish the project.

So what do you have to do?  You have to write down:

• Project objective
• Deliverables (products, documents)
• Services (support, training, warranty…)
• Applicable standards (management, quality, configuration management, development life cycle…)
• Acceptance criteria

And when you have all this information, you have to communicate it to your team.  It is extremely important that everyone working on the project knows what the outcome of the project has to be.

A good definition of the scope will not automatically guarantee the project success, but a vague (or non-existent) scope will lead to misunderstandings within the team and problems in the customer acceptance.