When I first started out as a project manager, starting up a project was REALLY stressful. There'd be a thousand and one things to do. There'd be project plans to draw up, templates to research, resources to secure. All adding up to a whole lot of stress.
As I got more experienced in project management, especially after my stint in the Change Management Team of a global investment bank, I realized there are some critical things you HAVE to do when starting up a project.
And yes, I know we've already gone through project management fundamentals which tell you what to do under according to the PMBOK.
That's all well and good. But I have a little page in my lovely hardcopy journal where I've scribbled "The First Six Things To Do When Starting A Project".
First 6 things I do when starting a project
These six things have saved my *** many, many times over. I tend to advocate that "getting it right upfront" will always triumph over being lazy and deferring important work till later.
Tip: One of my maxims for project management is to "get it right upfront". How many times have you gone through a project and later thought "Dang, I should have done this earlier". This has happened to me TOO MANY TIMES. I believe that if you get certain tough decisions or action items out of the way at the START of a project, you're going to save yourself a whole lot of pain later.
Curious? Let me elaborate more on the six things ...
What's first thing I do when I hear I've been assigned the PM of a project? For me, the FIRST thing to do is to read that dang Statement of Work.
Then read it AGAIN. And AGAIN.
I mean it. Read the Statement of Work THREE times. Every project has a "Statement of Work" document which spells out the objectives, scope, timeline, stakeholders, high-level requirements, assumptions, resources and other interesting facts about the project.
If you work in an end user environment, this document is sometimes called "High-Level Project Scope Document", "Project Initiation Report" or some other such name.
Regardless of what it is called, make sure you read it at least three times.
In The Fast Forward MBA In Project Management, Eric Verzuh observes that scope creep is one of the most common project afflictions. If you don't know the scope well, you also don't have good estimates of the project's costs, resources and timeline. An firm understanding of scope is one of the CORE requirements of any project manager.
Case Study: The Story Of A Deployment Gone Wrong
I'll tell you a little story. I was implementing a portfolio management system for a Malaysian bank. In our line, the last stage of the system implementation project is usually to "deploy" the system. That is, we were replacing the existing production system with the new one, usually done over one weekend.
I was at home in Singapore during the go-live weekend when one of the users from the bank called me. He told me he couldn't reconcile transactions and hence the system could not go live. This was a SERIOUS issue as it meant the go-live date promised to senior management would slip.
I went on to arrange a conference call with the users and started to troubleshoot the problem. We spent almost 10 man-days trying to resolve the issue - and still got nowhere.
But here's the real kicker - when my bosses heard I went to help the client on the deployment issue, they were furious! Why? Because deployment was not in our Statement of Work as a vendor! The time I spent helping the client was chargable work but I did not clarify this to the client upfront.
As a result, they took it for granted that I as PM should help in the situation and refused to pay for the 10 man-days of extra effort. It got pretty messy with my bosses after that.
So always remember - read the Statement of Work!
The second thing I do when I'm starting up a project is to dig up lessons learnt. There are a few ways of doing this:
Go through your Lessons Learnt Log from past projects. Even better if those past projects are of a similar nature of this new one.
Tip: Devote some time to logging down you're lessons learnt in a project on a weekly basis. For myself, I use a little note taking app called "Things" in my iPhone. I create a note called "List of Project Lessons Learnt" and whenever I'm free, I'll jot down some thoughts on lessons learnt.
These thoughts get captured in a formal lessons learnt log at the end of the project. Learning from your mistakes is very powerful indeed. And after three or four projects, I can guarantee you will start making less and less mistakes.
The other way of digging up lessons learnt before you start a project is to talk to other project managers. This is often overlooked. Many of us think we can "do it all" and refuse to talk to others. This is a MISTAKE. We all do better by tapping on the experience of others.
The next time you have to start a project, talk to someone who has project managed or even just been a team member in a similar project before. Talking to him or her for 30 minutes will yield tremendous insights to how you might run the project.
Resources are the life blood of a project. Without them, it is only the project manager and you alone can't accomplish much. Always make sure you secure your resources early.
I tell myself three things when it comes to booking resources.
Check with their manager first. Never assume that a resource or colleague is free to "help out a little" in your project. Check with their bosses and get permission first. I've seen many political battles in my office because resources get pulled from one project to another suddenly with no authorization.
Determine if the resource has the right skills and attitude. The basic requirement for a resource on my team is that he or she has the basic skills to do the job. However, you should go BEYOND skills. Look for attitude.
Tip: The right attitude in a resource can move mountains. I've observed some of my project team members who are young and not so skilled in domain expertise. Those who do well are those with the right attitude. Skills can always be learnt, but the right "can-do" attitude is very hard to come by. If you find such a resource, book him or her early!
The Project Charter is a central document which is developed in the very early stage of a project. It lays down the high-level scope, timeline and resources for the project. It also clarifies assumptions, dependencies, roles and responsibilities for a project.
Remember, many things in a project will be tough to clarify once you get started on delivery. Make sure you sort these things out before the project starts.
I like to create a draft of my document, then share it with my stakeholders - and let them have the chance to provide comments and input. This way, your stakeholders will feel they have a stake (forgive the pun) in the project.
Another use of the Project Charter is that it serves as a point of reference. If, during project delivery, anyone has questions about why the project was concieved, you can whip the document out and show it to them. You can show them why and also who approved the project and put their official stamp on it.
A sample of my Project Charter can be found here.
One important thing I do when I start up a project is to conduct a Method Adoption Workshop (or "MAW")
What's a Method Adoption Workshop?
Well, it's a series of meetings where I sit down with my lead team members (Business Analyst, Designer, Test Manager, etc.) to get them to agree on the approach towards delivering the project.
It's where templates, critical meetings and the "how-to" stuff gets worked out.
Doing a Method Adoption Workshop has tremendous benefits for the team. It clarifies roles and responsibilities and allows the team to go through the mental process of project delivery.
The final thing I do is to talk to stakeholders. You see, stakeholders need to be "warmed up" to the project. They're typically busy with their day-to-day work, and don't have time to understand what your project is about and what you'll be achieving for them.
It's important to conduct a "roadshow" to help stakeholders understand why you're doing your project. Why it matters to them and how their work will be impacted.
And if they have any questions, they can clarify it with you before the project kick-off. This also helps create relationships, so that when you actually move to delivery, stakeholders are a lot more cooperative.
I hope the above has helped you understand more about the key things you need to do when you start up a project. A lot of it is centered on understanding the scope of work you're delivering and also communication out to the stakeholders and project team.
As you get more and more experienced in project management, these will come naturally to you. So keep practising these tips and best of luck in your next project!
Are you wondering how to break into a Project Management?
Would you like to understand how others have successfully switched to a PM career?
Or discover what skills, certifications and domain / industry knowledge are required to excel in a PM role?
I’ve written a practical, easy-to-read guidebook that will help you find your best path to Project Management – one that leverages your unique skills, experiences and career background to your advantage.