The self-proclaimed leading voice of PM 2.0 says...
Traditional project management software applications, like MS Project, were created to support the waterfall project management style and are file-based. All the data on different projects are stored in various disconnected files and are usually accessible to the team members in the read-only mode. The existing combination of processes and tools does not encourage the team to contribute to project plans directly on a daily basis. With these solutions, someone has to connect all the pieces and bits of information into a bigger picture, and this person is the project manager. Traditional project management applications also are rarely suitable for distributed teams that work in a heterogeneous environment of multiple operating systems. This software is focused on the project manager and places him or her in the center of the project communications. It often means that the project manager must collect all the data and manually put the information into the project plan.
This of course might possibly be an opinion based on narrow experience.
But First Does Waterfall = Design, Code, Test?
First, let's establish a context for the notion of "waterfall." In the red herring approach to waterfall, a project is a series of tasks - design, code, test. Everyone I've ever come in contact with, from my first software development job as a graduate student writing FOCAL (an interpretative language for the PDP-15), to my last actual coding position, in the late 80's writing ADA for the rudder position holding underside pressure control loop for the 668 class submarine, no one ever produced a working product by doing design, code, test. I'd suggest those that execute software development in the design, code, test mode are foolish at best, and incompetent at worse. It happens I know - or at least there are stories of it happening. But that doesn't mean it right. Remember Pauli and his right and wrong quote.
All development was in increments. Write a little, test a little, establish a working baseline, take a break to think about the next steps. Move to the next step. Why was this the case in the domain I worked? Because in the embedded systems, of radar, sonar, real-time control - at least in those days - when the CPU encountered an error, it stopped running. "The run light went out" in PDP-15 and 2901 bit slice platform actually stopped dead. Code was written by punching holes in Mylar tape, feeding that into the tape reader, and then assembled, compiled, or simply "run" to produce the desired results. You went slowly, step by step, and knew what every change would produce. If you didn't you'd be stuck - dead in the water.
No more Waterfall comparisons - Let's get to the real Point of Managing Projects
All projects are a sequence of work activities. These work activities, themselves can be performed in parallel or in series, depending on several constraints:
- The availability of resources
- The logical dependencies of the intermediate products of the projects
In the embedded systems world, I can't develop the control algorithm in the absence of the I/O drivers for the sensor array. I can't develop the interrupt handling code for the sensor array, in the absence of the operating system scheduling algorithm. The functionality of the rudder holding control loop has to be built in a specific order - a sequence. A Waterfall of capabilities. Not design, code, test. Only a fool would do that. And hopefully only once. No, the order of the code must follow a sequence.
When asked "what's the purpose of time?" Einstein supposedly said
Time keeps everything from happening at once
So let's stop using waterfall as the anti-Christ of project management. All project activities occur in some sequential manner - in a series of work activities.
Deconstructing the PM 2.0 Opinion
So let's set some context. I was an early user of MSFT Project. Not Version 1.0, but Version 3 for DOS in 1986. The official Version 1 for Windows was on my desktop machine running under Windows 3.1. A complete piece of crap compared to TimeLine, which ran under DOS and made beautiful pictures of the projects we looked after. Hardware development using Sun-1 Cards running Unix, in the days when you could call Brian Kernighan and ask questions, and he'd send patches on 9-track tape
So the responses below come from anecdotal evidence of having walked the walk for some time - something around 30 years.
Traditional project management software applications, like MS Project, were created to support the waterfall project management style and are file-based.
The design of MSFT project is independent of its use. Waterfall of course is the code word for non-agile. An uninformed opinion of course. The notion of Waterfall - design - code - test is forbidden in the US DoD. No doubt, like all processes, there are misapplications. In the same way there are misapplications of Scrum and XP.
The plan, schedule, and cost baseline for a project is not held is a series of emails, tweets, IM messages. It is a database - the Performance Measurement Baseline. To do otherwise, for anything other than a trivial project, would be like planning the construction of your home (an activity I'll never want to do again), using a bunch of sticky notes on the dashboard of the construction superiors truck. It can be done, but the results are usually disappointing to all.
MSFT Project is used in a wide variety of project management process environments. Ranging for production sequential efforts to Scrum-based software development.
My favorite anecdote about using MSFT Project for only waterfall projects starts right here in Boulder. The Rally Software Microsoft Project connector.
All the data on different projects are stored in various disconnected files and are usually accessible to the team members in the read-only mode.
This is course is simply BAD project management. Project management possibly performed by naive and inexperienced project managers. MSFT Project is a "database," accessible through a variety of APIs. VBA for Project, VBA for Access, and VBA for Excel. All provide integrated management of the data held inside MSFT Project. Granted there are limits on the field types and the number of fields. This has been improved in 2007 and possibly 2010.
But no credible project manager would spread data in various disconnected files accessible on a "read-only" basis. Start simply by installing SharePoint (WSS) and move on to MOSS. Buy and install one of various Enterprise Project Management tools based on SharePoint. Use Safran for Project. Move up to SAP, PeopleSoft, and Oracle MSFT Project connectors. Possibly even wInsight.
We had a wonderful poster campaign at a very large nuclear weapons decommissioning site, where I lead one of the many Program Management Offices.
Don't do stupid things on purpose
Every time I hear some "expert" on project management, speak about what is essentially "doing stupid things," I think of those days when stupid things got people killed, suspended, or fired.
The existing combination of processes and tools does not encourage the team to contribute to project plans directly on a daily basis. With these solutions, someone has to connect all the pieces and bits of information into a bigger picture, and this person is the project manager.
This is utter nonsense in any credible project management process. Why would any sensible project manager prohibit contributions to project plans? Maybe not on a daily basis. You have to tune the management of the project to the rhythm of the project. This is once again one of those "stupid things" comments. Based either on inexperience, naivety, or simply ignorance of what project managers actually do for a living.
The NASA, Air Force, NavAir, and Army programs we work mandate weekly earned value management. Every Thursday we have a sit-down review with the Control Account Managers (CAM) to assess progress for the week, plans for next week, the next deliverables, next rolling wave. These processes are generally applicable to all enterprise-class projects no matter the domain or context. The business rhythm is built around the weekly EV process.
At the nuclear weapons plant decommissioning ($11B over 7 years), we had Plan of the Day during the last year to assure we stayed on schedule, on budget, and didn't kill anyone in the process.
The people who connect all the pieces are the same people who are willingly accountable for delivering all the pieces. The CAMs, Technical Leads, the workstream managers, the Program Planning and Controls staff, the Program Manager, and his deputies. There can't be successful in any other way.
Traditional project management applications also are rarely suitable for distributed teams that work in a heterogeneous environment of multiple operating systems. This software is focused on the project manager and places him or her in the center of the project communications. It often means that the project manager must collect all the data and manually put the information into the project plan.
Nonsense again. "rarely suitable?" Got any physical evidence? Most defense and space programs use distributed teams, multiple Integrated Project Teams (IPT), distributed sites, and wide varieties of tools, environments, and worse - management processes. It simply can't get done any other way.
There aren't enough people in a single building to produce products or services. The tools that support the Program Management pieces - not social networking - are enterprise-grade. SAP, Oracle for Construction, Microsoft Enterprise Project Management, specialized enterprise tools like wInsight. All collaborative web-based tools are tailorable to the needs of the user.
I get the sense that those wanting us to move to the PM 2.0 paradigm don't get out much to see how professional project managers do their job using the current toolsets.
