Can This Really Be True?

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 read-only mode. The existing combination of processes and tools does not encourage the team to contribute to project plans directly daily. With these solutions, someone has to connect all the pieces and bits of information into a bigger picture; this person is the project manager. Traditional project management applications are also 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 them in the center of the project communications. This often means the project manager must collect and manually put all the data into the project plan.

This, of course, might be an opinion based on narrow experience and not actual. MSFT Project Server answers every claim made.

But First, Does Waterfall = Design, Code, Test?

First, let's establish a context for the "waterfall." In the red herring approach to Waterfall, a project is a series of tasks - design, code, and 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 hands-on coding position in the late 80s writing ADA for the rudder position holding under a pressure control loop for the?668 class submarine, no one ever produced a working product by doing design, code, test.

After that position, I moved to managing software developers and then to managing software-intensive systems of system projects and programs.

Those who execute software development in the design, code, and test modes should be more wise and competent. It happens, I know—or at least there are stories of it happening. But that doesn't mean it is right. Remember?Pauli?and his right and wrong quote.

All development was in increments. Write a little, test, establish a working baseline, and 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, and 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 the 2901-bit slice platform stopped dead. Code was written by punching holes in Mylar tape, feeding that into the tape reader, and then assembling, compiling, or simply "running" to produce the desired results. You went slowly, step by step, and knew what every change would make.

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 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 only develop the control algorithm with the I/O drivers for the sensor array. I need help creating the interrupt handling code for the sensor array without the operating system scheduling algorithm. The rudder holding control loop's functionality must be built in a specific order—a sequence—a Waterfall of capabilities. Not design, code, or 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 sequentially - in a series of work activities.

Deconstructing the PM 2.0 Opinion

So, let's set some context. I was an early user of Microsoft 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—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 the 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. Like all processes, there are misapplications. In the same way, Scrum and XP are misapplied.

A project's plan, schedule, and cost baseline are not held in emails, tweets, or 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 truck. It can be done, but the results usually could be better for all.

MSFT Project is used in a wide variety of project management process environments, ranging from sequential production efforts to scrum-based software development.

My favorite anecdote about using MSFT Project only for waterfall projects starts here in Boulder: the Rally Software Microsoft Project connector.

• All the data on different projects is stored in various disconnected files, which are usually accessible to the team members in read-only mode.?

This, of course, is BAD project management. Naive and inexperienced project managers can perform project management. MSFT Project is a "database" accessible through various APIs. VBA for project, VBA for Access, and VBA for Excel. All provide integrated management of the data held inside the MSFT Project. Granted, there are limits on the field types and the number of fields.

We had a wonderful poster campaign at a large nuclear weapons decommissioning site, where I lead one of the many Program Management Offices.

Don't do stupid things on purpose.

Whenever 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 daily. With these solutions, someone has to connect all the pieces and bits of information into a bigger picture; this person is the project manager.?

This is nonsense in any credible project management process. Why would any sensible project manager prohibit contributions to project plans? Not daily. You have to tune the project's management to the project's rhythm. This is once again one of those "stupid things" comments. Based on inexperience,?naivety,?or simply ignorance of what project managers do for a living.

The?NASA, Air Force, NAVAir, and Army?programs we work with mandate weekly earned value management. Every Thursday, we have a sit-down review with the Control Account Managers (CAM) to assess the week's progress, plans for next week, deliverables, and the next rolling wave. These processes generally apply to all enterprise-class projects regardless of domain or context. The business rhythm is built around the weekly EV process.

At the nuclear weapons plant decommissioning ($9B over 7 years), we had a Plan of the Day during the last year to ensure 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, workstream managers, the Program Planning and Controls staff, and the Program Manager and his deputies. There can't be success any other way.

• Traditional project management applications are also 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 at the center of project communications. This often means the project manager must collect and manually enter all the data into the project plan.

Nonsense again. "rarely suitable?" Do you have any physical evidence? Most defense and space programs use multiple Integrated Project Teams (IPT), distributed sites, various tools, environments, and worse - management processes. It can't get done any other way.

More people must be in a single building to produce the products or services. The tools that support the Program Management pieces—not the social networking—are enterprise-grade: SAP, Oracle for Construction, Microsoft Enterprise Project Management, and specialized enterprise tools like wInsight. All collaborative web-based tools are tailored to the user's needs.

I understand that those who want us to move to the PM 2.0 paradigm only get a glimpse of how professional project managers do their jobs using the current toolsets.?