MS Project: Friend or Foe?

No comments
Post by Jim Van de Water

Scaling Project Plans in Ways Beyond MS Project

I’ve had a love/hate relationship with MS Project ever since I generated my first Gantt chart over 15 years ago. “Project” is arguably the ‘killer app’ of project planning – pervasive and powerful, while confounding and complex at the same time – both friend and foe. This dichotomy motivated me to find a way to reduce the length and complexity of big, repetitive Project plans by a factor of 10 or more. The approach may surprise you.

Today’s apps are supposed to be intuitive, simple and user-friendly.  Does MS Project pass these requirements?

  • Intuitive?  Hundreds (sometimes thousands) of line items that lack coherence or continuity. Iterative repeating tasks that resemble an endless staircase. Inability to easily gauge true percentage completion of a specific task or phase at any point in time.
  • Simple? Plans rapidly require a big screen television to view. Update processes that befuddle even project managers. Dependencies that cross the plan in a web-like fashion.
  • User-friendly? Complexity that blocks ability to use the plan to communicate effectively and to manage effort. Plans that can’t be grasped in whole by anyone on the project team.

I’d venture further to say that you probably don’t have to think too hard to write your own list of shortcomings, or to identify a project where Project helped ‘derail the train’.

Ok – so no one ever said that project planning is easy – or execution, for that matter. The plan should enable fluidity and transparency of execution. The execution should validate the (well-conceived) plan. That’s the yin and yang of project planning and execution. Are we feeling cozy with MS Project in that role?

I can feel the love – and the hate.

My approach is to limit the breath of a Project plan to what a single human being can absorb. If the entire Project plan can’t be understood, in its parts and in aggregate, the plan needs to be reconfigured, supplemented or scrapped. The plan – at inception and during execution – needs to remain a living artifact that invites understanding as it drives, tracks and reflects progress. The entire team should find the plan useful and accessible.  If not, the plan can place the entire project at risk.

Anything that repeats in regular cycles through the system development lifecycle (SDLC) is a candidate for an alternate – and arguably better – tracking method. List the units of work that need to be planned, assigned, and tracked.  Now create a spreadsheet with the steps of the development lifecycle across the top, and tasks that need to be tracked down the outside column.  The dates and status of task assignments are captured at the intersection of the SDLC steps and work units.

That’s right – this is sounding like project management using ‘old-school‘ Excel. Before you suggest expunging my PMP certification, consider that the majority of your teammates find Excel more approachable than Project. (You probably do too.)

Excel presents data in easily summed columns and rows, not hierarchical/network fashion like our friend Project. Excel has some incredibly rich functions for calculating working days, accounting for holidays and vacations, tying dependencies and such. The key enabler with Excel is that your entire team will be able to use the intuitive and simple functions like sort, filter, and search to cull out the noise and drill down to exactly what they need. The status of work assignments on the ‘tracker’ at this level of task detail can be as simple as this: 0 (working on it), 1 (completed), and 2 (held due to problems). Using Excel functions, I create another worksheet that generates a date-ordered list of assignments.

This approach enables more distinct steps to be tracked than a plan built only in Project. One of my recent projects had almost 400 individual development items tracked against 12 SDLC steps – a total of nearly 5000 individual steps tracked across time. This fits neatly into an Excel worksheet.  Not surprisingly, this does not fit neatly into MS Project.

Now tie together the granular Excel format with the dependency linking capability of Project.  The Project plan calls waves of repeated work at specific start and end dates -the Excel ‘tracker’ fills in the tasks between the two dates. When the repetitive process concludes, Project gets the completion date.  Gone are the staircases of repeating hierarchies and tasks, as well as the need for a wide-screen television to view. The team is presented with a worksheet that shows each repetitive wave of work and decomposes the waves down to the simplest unit of work – at the task level.

Our brains find hierarchies and networks challenging, but love the numerical and the linear. We can only bend MS Project so far before our brains, our plans, and our projects suffer. MS Project vets the dependencies between inputs and outputs at the high level. Excel captures the repetitive low-level details in an intuitive, simple and user-friendly format. The right combination of Project and Excel provides the team optimal support.

Leverage MS Project for its power to help manage your projects, but don’t be deceived.  Every tool has it limits. Consider complementing your MS Project plans with Excel ‘trackers’ to handle the repetitive work that Project does not handle gracefully. The time spent to build out a second layer of project tracking will pay big dividends.

 

Rey VillarMS Project: Friend or Foe?

Related Posts

Leave a Reply