How to Deliver a Successful Project – Part 4 – The Project Plan and Work Breakdown Structure (WBS)

Posted in: Blog, Methodologies, Project Delivery | Jan 12, 2013 at 8:42 AM

No comments

INTRODUCTION

This is a series:

Part 1. What Does “Successful” Mean?
Part 2. Start It By Defining THE Business Requirements
Part 3. Accurate Estimates, Quoting and Proposals
Part 4. The Project Plan and Work Breakdown Structure (WBS)
Part 5. Delivery: Communication is Key
Part 6. Managing Changes
Part 7. Project Closure

THE PROJECT PLAN

What is a project plan? Project plan is where you breakdown your project into tasks (similar to what you have in the business requirements document except the title of each task is shorter and more concise), assign a resource and the effort in hours.

The benefit of having a project plan is everyone has a clear idea when things are expected to due. I’ve had scenarios when my project manager suddenly expects me to demo the system to the client at a particular date while the system is not ready yet. This therefore creates pressure for me because I now have to be ready for the demo on that date. If we have a proper project plan there will be no surprises. I am bound and committed to each date on the plan.

This also applies for the client, too. A lot of the times when it comes to UAT, the client forgets and doesn’t have dedicated resources to do it. If the date is in the project plan, everyone has a clear picture of who is doing what and when things are due.

I normally use Microsoft Project to create the project plan but you can use other software or methods as you wish as long as you have the following:
– Task group title
– Task title
– Effort required (hours or days)
– Resource assigned

For example, in web design scenario I will have the following:

==

Project kick-off date: 01 Feb 2013

1 – UI Design (group)
——————————
1a) Photoshop cut-up into HTML mockup files (task)
32 hours (effort)
Joe Blog (resource)

1b) Meeting to demo mockup and to write any feedback
1 hour
Client ABC + Joe Blog

1c) Mockup implementation on CMS
40 hours
Joe Blog

ETC ETC ETC

==

Then you will have a clear picture when things are due and who is doing what.

DISCUSS ABOUT IT WITH THE STAKEHOLDERS AND TEAM MEMBERS

Have an hour meeting with your stakeholders and team members to present the project plan then ensure that your project plan is accessible by both the stakeholders and your team members. Make sure that everyone is happy with the dates. This is why it is important for you to create the project plan based on the tasks written in the business requirements document.

This way everyone is bound and committed to it. If someone says, “Oh sorry..am I meant to do that by this date?” then you can say, “Yeah man…it’s in the project plan”.

CONCLUSION

Is project plan that important? Yes it is! Let me reiterate, it is used to avoid any surprises. It ensures that everyone is committed to each  date written on the plan.

From my experience project plan is never accurate. There will always be things that happen along the way. That is OK. Again, it’s still better to have a visible plan than not having it at all. Make sure you update the project plan weekly and send notification to both the stakeholders and team members.

No Comments Yet.