MSFT Project for Software Projects?

Through a chain of links starting at Jack Dahlgren's site I came across a post on Target Process. Ignoring the fact that they sell a competitor to MSFT Project, the post raised some interesting questions.

1. MS Project is based on waterfall
2. MS Project is a desktop application
3. MS Project is not integrated

Mary Popendieck asked last night  for materials on how to do "scheduling." I have lots of guidebooks mostly from government contracts as well as internal framework. By the way PMBOK Guide has NO guidance for how to actually schedule something. Anyway the three items above are "felt needs" for someone. Felt in the way of objections to the tool. So let's start down the list in the context of how a modern aerospace firm manages projects that contain lots of software - not pure software projects, but close enough to expose some larger problems.

MS Project is Based on Waterfall

Project provides the means to construct a network of tasks, connected by links. Constraints can be placed on these relationships as well as the duration of the tasks. As an aside this approach is called "work on node" versus the "work on link." This topology has NOTHING to do with Waterfall. It is a finite graph paradigm that can be used to construct a Waterfall representation of a project, but MS Project does not itself assume Waterfall. Nor does any other project management tool.

The claim that Waterfall is bad for software development may have some truth. It probably depends on what one means specifically by "waterfall," and at work resolution the individual tasks are defined.

I would suggest that the "waterfall" approach is inappropriate for detailed task planning. The XP or Scrum approach is much better suited to discovery design software development. But this has little to do with the way project networks are constructed or managed in MS Project.

MSFT Project is NOT based on Waterfall. Waterfall is a planning paradigm where work is sequenced with large grained feedback loops at the end of major cycles - design, code, test. As well Waterfall is not an accepted practice in FAR 15.2 procurement projects. Don't use it. The mature project management first don't use it. Neither should you.

Don't do stupid things on purpose - Waterfall is one of those

MS Project is a Desktop Application

The project plans need to be made visible. Buy Project Server and be done with it. Or better yet hang the charts on the wall and create a "Big Visible Chart" - a Wall of Truth as we refer to it here in the manned spaceflight business.

MS Project is Not Integrated

This is a simple matter of programming. Before our Project Server installation, we integrated .mpp files with Doors (an equivalent to ReqPro which provides a connection), with the Risk Tool (ARMin our case) and using VB and VBA constructed Power Point to represent almost anything we needed.

It seems that the PWA and Project Server project is needed here. As well some better understanding of how project planning needs to take place and be situationally focused.

• DO NOT plan daily tasks for software development - use an iteration process, where the plan for the iteration is done prior to its start and the development team works off the deliverables in the iteration in what ever way works for them. This is call "Time Boxed Scheduling," Rolling Wave for larger duration iterations. XP and Scrum know how to do this quite well.
• DO NOT plan in a Waterfall manner. Use an Event Based Planning process (IMP/IMS is the way the government does it). This defines the increasing maturity of the project through assessment points - Program Event - measured with Significant Accomplishments and their Accomplishment Criteria. This approach has worked very well in large IT projects and can be scaled down to smaller ones as well.
• DO NOT confuse a good principle with a poor practice. Complaining about Waterfall, Integration, and visibility without providing alternatives is just complaining and it is poor project management. Alternatives, trades, risk adjusted planning are all part of good project management principles and practices.

So Back to Mary's Request

The materials in the public domain that describe how to "plan" are focused on mission critical projects - aerospace, defense systems, Department of Energy projects and the like.

Software planning processes "should" be focused in agile development methods - XP, Scrum, DSDM, Crystal, and other - see the agile sites for destails.

Blending is done in several domains.