One of my friends recently asked me for advice on his project:
Project planning is a broad topic and there are many factors that go into it. That’s why I dug deeper to understand what Carlo was actually having trouble with:
If you think about it closely, the issue with project planning is:
- Effort estimations: You have to get realistic effort estimations. If your estimations are too far off your project will face trouble and you’ll run into delay.
- Dependencies: You need to understand how project tasks relate to each other in order to create a stable project plan. You need to understand which task comes first, which comes second and so on. If your task plan is messed up, this will be felt in the project later.
- Risks: Let’s say you’ve diligently created a project plan. And then something unexpected happens. Someone on your team falls sick, a vendor does not deliver or you face unexpected issues while testing your prototype software. What happens? Your project timeline is at risk.
If you get those three points right, you have a pretty solid project plan.
It turned out that estimations were the area of concern for my friend:
That’s a great question. And it really hits on what project planning is actually about.
It’s the fear every project manager has to deal with:
“What if I have to change the project plan later?”
So, how can you create a good project plan when you have limited information?
You can’t estimate what you don’t know
In the case of Carlo’s project he’s still in the initiation phase of the project, and he needs to submit a project plan to the customer. At this stage key information is missing:
- Customer requirements may not be 100% clear
- Resources may not be fully confirmed
- Technical details haven’t been gathered
We can’t design a reliable project timeline when we haven’t got all the information. All we can do is create a preliminary project schedule and communicate to the customer that it might change later. Of course there’s a catch to it. Having to change the project plan later on doesn’t make a good impression on the customer.
A good-enough preliminary project plan
How can Carlo still create a project plan and minimize the risk of having to change it later?
3 strategies came to my mind:
- Compare with previous projects – what is different?
- Run the numbers
- Setting conditions
Comparing with previous projects
Assuming that it’s not the first project you’re doing in this area, you have some previous projects to compare your current project against. Take a close look at the new project and ask yourself: “How does this project compare to any projects we’ve run before?”
For example:
- Does the project involve new tools? E.g. new software your team has to learn first.
- Does it concern a new a industry?
- Are there any new requirements?
- Does it have much larger scale? (a bigger project)
- Does it involve new countries you haven’t dealt with before?
From the insights you gather at this step, you are able to draw conclusions about how it may impact the project timeline. For example you may conclude:
“So far we’ve only worked with companies in the civilian sector. Our new client is part of the military industry, so we’ll have to get military clearance first which may take up to 3 months”.
Then you factor in the additional time in the project schedule.
Another example would be to consider the learning curve in a project involving some new skill or tool. You might suggest something like:
“We’ve never implemented any interface involving SAP S/4 HANA. We may have to invest at least a month to get our team up to speed so that they understand what’s different”.
Boom! Now you have identified an important determining factor on the project timeline and thus are able to craft a more stable project plan.
Run the numbers
I used to work as an IT project manager for many years where I was in charge of consolidating our plants — including processes and data — on a centralized IT system.
From a process point of view all plants were more or less similar. However they differed in size. Some plants had 300 end-users while others had only 30 people. The user base had an impact on our project timeline as more users also mean more training effort.
Another driver for project performance in our projects was data volume. Some engineering units had thousands of CAD drawings that we had to transfer to the new system while others only had a few hundred. More data also means higher migration effort, meaning the timeline has to be stretched, both because it’s more effort but also due to the inherent uncertainties (e.g. data quality may not be perfect).
You have to carefully check what are the main drivers behind project performance in your project. Is it number of users? Is it logistical factors? Is it data volume?
Depending on your findings you can derive the impact on the project timeline, e.g. “In this project we are dealing with twice the amount of data records, so we have to extend the timeline by at least 1.5”.
Making the proposal conditional on certain requirements
The key to creating solid project proposals and project plans is to understand what parts in the project are within your circle of influence and which parts are not. Usually what’s within your control is the stuff your team is doing.
Unlike that, you don’t have control over your customer’s resources, technology, operations etc. And I’m sure you’ll agree that you can’t take over responsibility over things you have no control over, right?
So, what you do is set clear conditions under which the project can be executed in a safe way and which allow you to make reliable time estimates.
Take these examples taken from my projects:
“Migration data must be provided in a pre-defined format specified by the contractor”
- By adding this statement in the proposal you shift some of the risk and uncertainty to the customer side. The customer has to provide data in a format defined by the contractor, making the data import a lot easier and more predictable.
- It sets out clear rules that must be followed to ensure time targets can be met.
“Effort and time estimates are calculcated for the establishment of one system interface”
- Larger companies usually run a huge number of IT systems, and their staff may not be aware of every single system. That’s why systems often get missed in IT projects, resulting in expensive and time-consuming extra work.
- By basing your calculations on the hookup of one customer IT system, your predictions become more reliable and
“Project team members are expected to have a good command of English”
- Efficient and effective communication is the glue of every project. It only works if everybody speaks the same language, and at a good enough level.
- Projects really can get into trouble if things get delayed due to misunderstandings. That’s why in multi country projects you have to demand a certain language skill level.
What conditions make sense for your project?
Project management is about achieving the impossible
Finally, remember that a project plan is NEVER going to be perfect. At some stage you just have to commit to get it done and do everything possible (and impossible) to make sure the timeline is met. This is what characterizes a great project manager. Finding solutions where others see problems.
Good luck!
