How to start a new Project?

How to start a new Project?

Thing #1: Read The Statement Of Work

Read Statement of Work at least 3 times.

Then read it AGAIN. And AGAIN.

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.

It is sometimes called “High-Level Project Scope Document”, “Project Initiation Report” or some other such name.

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.


Thing #2: Dig Up Lessons Learnt

Go through your Lessons Learnt Log from past projects. Even better if those past projects are of a similar nature to this new one.

Tip: Devote some time to logging down you’re lessons learnt in a project on a weekly basis.

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.

Thing #3: Secure Resources

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.

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: 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!

Thing #4: Define Project Charter

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 conceived, 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.

Thing #5: Conduct A Method Adoption Workshop

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.

Thing #6: Talk To Stakeholders

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.

Define Project Success

A project can only be successful if the success criteria were defined upfront (and I have seen many cases of projects that skip that part..). When starting on a project, it's essential to work actively with the organization that owns the project to define success across three tiers:

• Tier 1: Project completion success: this is about defining the criteria by which the process of delivering the project is successful. Essentially this addresses the classic "are we on time, budget, on scope, quality?" (adapted to whichever PM method you might be using). It is limited to the duration of the project and success can be measured as soon as the project is officially completed (with intermediary measures being taken of course as part of project control processes).
• Tier 2: Product/service success: this is about defining the criteria by which the product or service delivered is deemed successful (e.g. system is used by all users in scope, uptime is 99.99%, customer satisfaction has increased by 25%, etc.). These criteria need to be measured once the product/service is implemented and over a defined period of time.
• Tier 3: Business success: this is about defining the criteria by which the product/service delivered brings value to the overall organisation, and how it contributes financially and/or strategically to the business. For examples: financial value contribution (increased turnover, profit, etc.), competitive advantage (eg. x points marketshare won), etc.
  => Overall success: As per the examples mentionned in your question, you can be successful on one tier but not others. Ultimately I think tier 1 matters little if tiers 2 and 3 are not met, and the overall success needs to be defined and agreed as part of this exercise.

When it comes to accountabilities for success, they should be assigned according to tier:

• 1 - Project completion success: PM (and project team).
• 2 - Product/service success: Product/Service Owner.
• 3 - Business success: Project Sponsor.

The process of "success definition" should also cover how the different criteria will be measured (targets, measurements, time, etc.).

When it comes to these five success criteria, the survey found:

Scope: 87.3 percent said that meeting the actual needs of stakeholders is more important than building the system to specification.

Quality: 87.3 percent said that delivering high quality is more important than delivering on time and on budget.

Money: 79.6 percent said that providing the best return on investment (ROI) is more important than delivering a system under budget.

Staff: 75.8 percent said that having a healthy, both mentally and physically, workplace is more important than delivering on time and on budget.

Schedule: 61.3 percent of respondents said that it is more important to deliver a system when it is ready to be shipped than to deliver it on time.