What's Wrong With This Picture

    I received an email asking me to fill out a survey from PMI.  I thought I'd respond just to see what it's all about. The survey asked about the duties of a Project Scheduler and if I performed any of these in my work assignment. These duties include:

• Using the Project Scope Statement, identifies, sequences and sets time durations for project activities
• Prepares and updates project network diagram and resource requirements
• Prepares and submits Baseline Schedule for approvals; revises as needed
• Inputs the schedule activity descriptions, durations and logical connections, and runs scheduling software program
• Updates the schedule by inputting progress and re-calculates the status of schedule
• Makes special scheduling calculations and updates for any change orders, unforeseen project conditions, or requests for time extension
• Participates in time-related decision-making using the schedule structure and database to do “what if” scenarios

Now these "duties" sound OK on the surface. And in fact, other than the first one are probably the right description of what's been called "Project Controls" in most places I've worked.
    But the first bullet struck me as the source of failure for most projects I've been on - IT and non-IT. Identifying, sequencing, and assigning durations to tasks is NOT the role of the Project Scheduler, it is the role of the project team, along with the Project Scheduler. The Work Package Manager, the Customer, the entire team that is accountable for delivering the business capabilities and their associated value to the customer - did I mention the Customer is accountable for the credibility of these activities as well.

• How could the Project Scheduler identify the duration of the work activities?
• How could the Project Schedule place these activities in their proper sequence?

    The core fundamental difference between a "traditional" approach to project management (e.g PMI's view of managing a project) and an agile approach to managing projects is this...

The Customer is in the Loop. The Customer IS the Loop. The Subject Matter Expert and the Customer are joined at the hip. The Business Capabilities and Resulting Business Value is Defined by the Customer. The Subject Matter Expert provides guidance and expertise regarding the "do ability" of these Business Capabilities. The resulting Plan and supporting Schedule are jointly created by the Project Team.

Now there are some good things to be said about PMI's PMBOK(r). It provides an overview of the processes of managing a project and the knowledge areas on which those processes areas are based. All good stuff, all needed in some form for any successful project to reach its goal. But here is the problem. In Figure 3.4 on page 42 of PMBOK 3rd Edition the "Customer" is connected to the process groups (Initiating, Planning, Executing, Monitoring and Controlling, and Closing) in only two places.

• At the beginning, when the project is initiated
• At the end, when the project is closed out

    What, no customer connection during the other activities of the project - this is called "launch and leave" in the standoff weapons business.
    Figure 3.5 on Page 43, shows the boundaries of a project, built around the Plan, Do, Check, Act,   paradigm. Which by the way is a "Problem Solving" process, which may be suited to managing projects if project are seen as "problems to be solved." The ASQ (American Society for Quality) described PDCA as a four step model for carrying out change. Even more interestingly they (ASQ) suggest it be used:

• As a model for continuous improvement
• When starting a new improvement project
• When developing a new or improved design of a process, product or service
• When defining a repetitive work process
• When planning data collection and analysis in order to verify and prioritize problems or root causes
• When implementing any change

Note the repetitive work cycle suggestion. Most IT projects I come across are "one offs." 

    Interestingly the "End Users" are outside the boundaries at the completion of the project and the "Project Initiator / Sponsor" is outside the boundaries of the project during its formation.
    This view lays the foundation for "trouble in River City." How is the project and its leadership to actually get feedback, understanding, and verification that the intermediate results they're working on will be what is wanted and needed by the customer.
    The answer of course is specifications...the kiss of death for any IT project. QED