9 Benefits of Tracking Project Schedule

By | January 19th, 2016|Project Tracking|0 Comments

Are you Tracking Project Schedule Regularly?

tracking project schedule

There can be only 2 answers to the above question. Yes and No.

I am appalled when I hear PMs say No to the above question. I hear all sorts of myriad funny reasons for not tracking Project Schedule. Here are some of them:

  • Why should I track Project Schedule? The project is going on just fine.
  • Oh! The customer demanded to prepare a Schedule and we prepared it. Now, there is no reason to waste more time on it.
  • There was a project audit some time ago. We prepared a Schedule to keep Auditors happy. Otherwise developing or tracking it is not at all required.
  • Tracking Project Schedule is just a waste of time. It does not provide any tangible benefit.
  • I never track Project Schedule and I have been managing projects for donkey years.
  • Tracking Project Schedule is not a priority at this time.

But many other PMs say Yes to the above question.

It is true that many PMs do track Project Schedule regularly. But some of them do not understand how to do it properly. They would just enter actual dates and/or duration and be done with it. They do not analyse the Actual Project data to see the variances, modify Project Network as necessary, do forecasting etc.

A good PM must use a Project Scheduling tool like RationalPlan to develop and track Project Schedule. The tracking can be done without a tool also but a tool helps in saving time and improving productivity.

In the next article I will throw some more light on what is meant by tracking and how one should track the Schedule. But for now let us understand why Project Schedule tracking is important. Let us take a look at some of its benefits. (more…)

Work Breakdown Structure Made Easy

By | January 17th, 2011|Project Management Software|4 Comments

“Would you please help me print out this ‘WBS’? It won’t fit in one page. I have a status meeting with the Sponsor in 30 minutes!” a colleague of mine approached me and asked. “This is not a WBS! It is a Schedule in a form of hierarchal structure.” I said sarcastically when I saw her WBS. She listed all project deliverables, and listed all activities below each one. This is not what a WBS is intended to be used for. Does your sponsor or client need to know how you’re going to complete each deliverable? Do you really need to present a 100+ boxes on your WBS to get your sponsor agree on what’s included and what’s excluded in your project scope? Absolutely not.

The primary benefits of having a WBS in any successful project dictate the need to keep it simple. Firstly, a WBS depicts the boundaries of project scope. A client or a sponsor can easily sign off a well-structured WBS as it includes all project scope and excludes whatever out of scope. Secondly, it ensures that effort is not wasted on unnecessary or out-of-scope deliverables. That is, if the WBS lists a redundant Work Package, this would require extra resources, time, and cost. Finally, a good WBS can be used on a project dashboard to communicate scope (changes) without confusing stakeholders with scores of activities needed to complete deliverables. The latter point is actually the key to build a good WBS. A WBS does not include activities; it only lists deliverables down to the Work Package level. Leave listing activities to the Project Schedule. WBS is composed of tangible deliverables without activities whereas a Schedule describes all activities required to complete those deliverables outlined in the WBS.

From another perspective, a WBS represents the project lifecycle that is different from the PM Process Groups. WBS is not used to chart Initiating, Planning, Executing, Monitoring & Controlling, and Closing of a project. These are process groups that describe how you manage a project from start to end but not what the project includes and what it excludes (scope). On the other hand, a project lifecycle describes the phases into which a project evolves to complete each of the agreed upon deliverables. Hence, one of the most commonly-used WBS’s is breaking down the project into phases, deliverables, sub-deliverables, and Work Packages that collectively constitutes the overall scope of the project.

If WBS represents the lifecycle, how should PM processes be represented as part of the project effort? Project Management is actually a phase in the WBS that has its own deliverables, sub-deliverables, and Work Packages. Taking a software development project as an example, the WBS shown in figure (1) is what is expected to represent the lifecycle and scope of the project (WBS in its initial structure for illustration purposes).

(more…)