Herding Cats

The Next MUST Read Book

After Reinventing Project Management, the next book that is a "Must Read" is IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Peter Weill and Jeanne W. Ross, Harvard Business School.
    Much of the confusion around project management in the IT business starts when the concept of Governance is skipped.

• Who gets to decide what to do?
• Who gets to decide what done looks like?
• How can these decisions be connected with the business strategy?
• How can we tell we're making the right decisions?

    Coupling IT Governance and Reinventing Project Management into a three stage process lays the foundation for project success

1. Governance - what are the rules for managing the IT department in its quest to provide value to the organization?
2. Request to Project - what projects shoudl be done for the business? Who gets to participate in these decisions? How can we "Guard the Front Door of IT," so the resources and capabilities in place today can deliver value for tomorrow?
3. Project to Delivery - once the portfolio of projects is defined (project selection using some form of portfolio management), how can they be assured to complete on-time, on-budget, and deliver the promised business value?

    This is the role of the Program Management and Project Management professionals in IT. All the smoke mirrors, and magic beans of project management must address these questions first before any credible discussion can take place about the specifics of managing any one project to its successful conclusion.

Galileo Galilei was probably not a good project manager

    When it is mentioned that the Newtonian aspects of our world, or how Galileo established the basis of our modern thinking about how the worlds works, there are several missing pieces. The notion that determinism is the basis of project management, several gaps are present - both in the project management paradigm and the current (as of the early 20th century) paradigm of physics. Let's start with the project management paradigm
    The first is the current DID-81650 guidance to include Statistical Risk Analysis of cost and schedule in all procurements greater than $20M. Now $20M is a lot of money in some quarters. In other places it's hardly worth bending over to pick up the change.
    In all cases probabilistic risk analysis of cost, schedule, and technical performance is just good project management. A recent post on the Five Easy Pieces of Risk Management, presented at the recent Denver PMI Symposium and the upcoming PMI College of Scheduling conference with "Establishing the Performance Measurement Baseline," both speak to the mandatory process is not using point estimates, understanding the statistical nature of all estimates, and the probabilities of completing on or before a date and at or under a cost in all projects, no matter the size.
    In the end of course the Galilean spell (as some have referred to this) was broken in 1950's when Murry Gell-man shared a hall way with Richard Feynman, who together developed Quantum Electrodynamics and the initial foundations of Quark theory that is the basis of the current Standard Model. When Gell-Man speaks to regularities, he is not speaking about determinism, but rather predictable outcomes of a theory - the Standard Model, QED, Quantum Chromodynamics, and now some remaining parts of String Theory. All of which are based in indeterminism at the quantum level and reflected in deterministic behaviors at the macro level.
     The four forces of nature (electromagnetic, weak, strong, and gravitational) are spoken to in part in the Standard Model (EM, Weak, Strong). Gravity is the remaining force to be unified in the quest for the Theory of Everything.

The Theory of Project Management
    No matter your stripes regarding the validity or obsolescence of the conventional approaches to project management, the US Department of Defense and all others subject to DID-81650 mandate a Monte Carlo Simulation of the probabilistic nature of cost, schedule, and technical performance.
    Galileo would be proud of  PM's with the experience necessary to recognize these underlying variabilities, driven by natural variance, known, unknown, and unknowable statistical process who have moved far beyond his "clockwork" approach of nature.

Cynics v. Skeptics in Project Management

    Much is being written lately about the failures of conventional project management processes. It seems  there is a difference thought between the skeptics about these processes (for all the right reasons) and the cynics about these processes (for many of the wrong reasons).
    I came across some statements about the differences between skeptics and cynics:

• A cynic is not merely one who reads bitter lessons from the past, he is one who is prematurely disappointed in the future - Sidney Harris
• The skeptic doesn’t trust the analysis… the cynic doesn’t trust the analyst
• No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art - Henry Petrosky

So a skeptic about the conventional notion of a water fall schedule could replace the long waiting periods between progress assessments with shorter ones and get fine grained Earned Value Management. Weekly EV, bi-monthly performance reports and the mandatory monthly Contract Performance Report. The cynic would say conventional performance measures never worked, can't work and my "magic beans" are the solution to the problem.
    The skeptic would know that task durations are random variables drawn from an underlying statistical distribution and assess the critical path of a schedule accordingly. The cynic would claim PERT and CPM are wrong without replacing the need to determine - with some level of confidence the completion date and cost at completion of a project.
    It's a large list. Skeptics make good project managers.

Simple Conditions for Project Success

From the recent NASA Project Management Challenge are four conditions for project success:

1. You can't succeed if you can't manage the work, people, customer, and the environment
2. You can't manage these project elements if you can't measure their current state, their desired end state, and the progress being made toward that end state
3. You can't measure these states if you can't define what they are in some units meaningful to all the participants
4. You can't define these units of measure unless you understand the technical, operational, human factors, business, and political aspects of the project

The results of these "understandings" is represented in the Performance Measurement Baseline. The PMB is used to answer:

• How much will this cost (the all in cost) when we're done?
• When will we be done? Done, done, means all done, nothing else to do.
• What does done look like when we get there? Is the description of done acknowledged by all the participants, including the costomer?

The repeated mantra:

If you're not asking and answering questions like these - you're not doing project management.

You may be doing something else, but it's not project management.

Three Simple Questions

    From a  government program management review meeting this week, I came away with three simple questions that must be answered by any project management process. Anyone claiming to be a project manager, program manager, or anyone conjecturing that their new, shiny, and magical project management method should replace the one we're using now:

1. Is the project making progress as planned?
2. Is management - project, business and technical - pro-actively addressing problems in the project as they arise?
3. Are there any surprises coming our way?

    That's it. That's all there is. Ok, maybe a few more questions. But if we can't answer these questions in some credible manner, then the project is not being managed. And since project management is a verb, "management" is what project managers do, they "manage projects."
    All the other activities around projects, no matter how important they are, they appear to be, or they want to be - if you can't answer these questions, everything else is a moot point.

Thermostatic Control

    There is a popular misunderstanding that the thermostatic control paradigm is how projects are managed in the real world. This starts with the misunderstanding of how "Program Planning and Controls" are applied on projects and how the notion of control is defined in places like PMBOK.
    NO WHERE in PMBOK and I mean NO WHERE does it define that a Thermostatic Control process should be used. On the other side, the Thermostatic Control process is actually not defined - it is used as the basis of criticism without a context, a domain, or a definition. This is one of those redherring approaches so popular these days. What PMBOK does say is that schedule control is concerned with:

• Determining the current status of the project schedule - where are we along the path to completion?
• Influencing the factors that create schedule changes - what's driving change, what's the impact of these changes, are these changes beneficial to the project, if not, how can we protect the project from these undesirable changes?
• Determining that the project schedule has changed - what is an acceptable change, what is an unacceptable change? How can we tell the difference between the two?
• Managing the actual changes as they occur - managing change does not mean restricting change. It means making good decisions about accepting change, its impact on the schedule and the beneficial outcomes from change on the delivered value from the project

    So, as a project manager would you say "these are NOT in my job description?" PMBOK goes on to say things about what are the inputs, techniques, and outputs of the schedule control processes.
    Before that is answered, what is the concept of "control" in general. As a recovering control systems engineer (missile, torpedo, and submarine guidance controls, fault tolerant turbine and nuclear power plant controls and other little gadgets like that), the notion of control ranges from simple (and simple minded) to complex and to very complex.
    There are two basic classes of controls - open loop and closed loop. The closed loop control has feedback, that can be linear or non-linear. One simple example is the home heating control for a furnace.

• Too cold in the room, turn on the furnace and measure the temperature rise
• When the measured temperature reaches the set point, turn off the furnace
• Repeat forever

    There are some minor details like the error band around the set point, the hold or dwell time on the set point, so the furnace doesn't "hunt," the delay time so the furnace doesn't constantly cycle. But that's the general theory.
    With the closed loop controls, feedback is the primary data element, along with the "set point" (the drive) and the "command" (the output). One parameter of these simple controls is the "sample rate." The furnace control is usually a continuous loop - an analog device. But digital devices are used as well. They implement some sort of digital algorithm - read computer program - that samples the environment and decides what to change in that environment. This "decision" process is itself an algorithm - the control algorithm The cruise control on your car is a digital controller that sense the speed, the "set point," the torque on the engine (shifting the transmission) and other sensor inputs. It then "commands" the throttle to "hold the set point speed."
    The sample rate is relatively fast on my Honda Civic SI. It can hold the set point within 1 MPH over a variety of conditions. Our GMC Suburban had a poor cruise control that would get confused in the mountains and put itself off line when heavy engine loads occurred.

Project Management Control Systems
    Projects are human, technical, and organization activities that are subject to "controls." In the absence of some kind of control a project would be a an open loop free for all. But are projects controlled by the simple minded thermostatic control loop? I say simple minded because those conjecturing that thermostatic controls don't work haven't described the control loop:

• Sample rate
• Loop response function
• Linear or non-linear characteristics of the sensors, control loop algorithms, output actuators and the response function of the "system under control."
• Is there feed forward as well as feed back loops?
• Are these loops adaptive, self tuning, operational in the presence of noise, spike disruptions, out of band transits?

    These authors don't say how control loops work. But that's to be expected, since it much easier to take that approach - "Thermostatic control don't work," than to actually understand the principles of control in general and project controls specifically. I guess the use of "magic beans" to manage projects can take you a long way in the project management seminar business.
    The concept "sample rate" is the core concept of project management controls:

• eXtreme Programming (XP) samples the project status and makes steering commands every      two weeks.
• The Rocky Flats Environmental Technology Site (www.rfets.gov) project management control      systems gathered sensor data and made steering commands every day. The Plan of the Day and the Plan of the Week were the basis.
• Scrum's sample rate is a month and a week.
• The conventional water fall - the redherring of agile and feral project managers samples on too long an interval

Remember from a past post...

How Long Are You Willing To Wait Before You Discover You Are Late?

Make the sampling rate half or less than that. But not too fast since that can create digital noise as well and the loop will be overcontrolled.

So Where Do the Proponents of Thermostatic Control as an Obsolete Theory Go Wrong?
    The core missing element in the design of any control system is to first characterize the "system under control." To not do this would be like taking your furnace control and attaching it to the F-35 Strike Fighter's fuel throttle control loop to maintain supersonic cruise. A really dumb idea. Remember another previous post

Don't do stupid things on purpose

    Using the wrong control algorithm is doing stupid things on purpose. Just like writing the schedule and not updating it, like calculating the critical path and do redoing it every week with "actuals to date." Or like defining the requirements and assuming they're not going to change. Or not measuring the "capacity for work," and assuming everyone is working at 90%. Doing stupid things on purpose is bad project management.

Sample Rates, Control Response, and Control Algorithms
    Without getting into the details of project controls, the project manager needs the following to make decisions. These decisions may not result in success. Only those with "magic beans" are selling success.

• What is the business rhythm for the project? On our project this is actually called the "Business Rhythms Meeting." In our case it's once a      week, mid week.
• What is the response time of the "system under control?" How fast can we turn the ship? An hour, a day, a week, a month? Depends on the culture, work environment, regulatory environment, safety consideration, management style. Tons of explicit and tacit variables.
• What is the actual control algorithm? Linear input, process output.
  • "We're driving too fast, slow down to the speed limit."
  • "We're driving into the ditch, move the car back into the proper lane, but no  further or you'll crash into oncoming traffic."
  • "We're landing hot on the carrier, bring the nose up, but not too much, slow  down with the spoilers, but not too much, add a little power to keep on  the bubble, but not too much, add a little left rudder as we pass the  island wake, but not too much, ..., ..., ... and catch the number 3  wire."
• How noisy is the input data and the output commands?
  • The autosteering on a boat has the dynamics of the hull in the loop.
  • Steering your car automatically includes the dynamics of the mechanics of the car.  My Honda SI is ultra sensitive. It took a few weeks to drive a speed and  not drift while commuting. Driving the Suburban is a point and watch  process. With summer tires the Honda is "twitchy" - you  gotta pay attention.

    Finally the notion that feedback is the cause poor control is misinformed. The processing of the feedback – how it is used in the algorithm is the first critical item. Second is that most modern controllers, other than simple furnace controls use “feed forward” control algorithms. These anticipatory commends keep airplanes on course, trains running at optimal fuel consumption levels, pace makers keeping their hosts alive. It’s the anticipatory aspects of a control system that make it applicable to project management.
    Driving in the rear view mirror – using a simple minded control loop to manage a complex system with built in and external variances is “doing stupid things on purpose.”

Back To Projects
    To claim the project control system of today "sorta" work is of course nonsense. There are spectacular failures - Big Dig, IRS system replacement. But these critics never seem to provide examples of working projects, the ratio of working to failed, or any sort of analysis as to why a specific project failed and the casual connection with the project control system. Too much work, selling "magic beans" is easier.
    I was witness to the last launch of Titan. It was scheduled to go from Vandenberg at 11:05 October 19, 2005. There was a glitch a few minutes before launch and a hold caused the "Planned" launch to slip. The 2nd stage was burned longer to make up the time, because there was a multi-billion $ National Reconnaissance Office payload that needed to be on orbit at a specific time.
    Now this is an extreme I know, but the project controls algorithm to get Titan off is adaptive, incremental, iterative, based in EAI-748B Earned Value, risk adjusted for every work package from design to flight, and managed by profession project, program, and planning and controls engineers - and most importantly tuned for the rhythm of launch vehicle operations.
    Scrum, XP, DSDM, Prince2, RUP and other project management methods also have natural business rhythms, different rhythms for different problems. Pick the right one, don't pick the wrong one. Don't do stupid things on purpose.

The Final Test Question
    What ever project control algorithm is used, no matter how cock-a-mammy it might be or how field proven it is for the business rhythm it needs to answer the following:

1. How much will this project cost in the end?
2. When will we be done?
3. What does done look like when we get there?
4. How many and of what types of people, materials, resources, and facilities do we need?
5. How do these people, materials, resources, and facilities need to interact with each other?
6. What risks to our success exist and what mitigations are we going to take against them?
7. How will we recognize that the products or services resulting from the project are acceptable      to the "customer" in whatever way you define the customer?

    So conjecturing the thermostatic algorithm is ineffectual, needs to be replaced with the answers to those questions in some definitive way in order to have project managers consider them credible. Otherwise, you're still in the "magic beans" business, not the project management business.

The BIG Question for any project management process

There is one and only one question that needs to be asked when ever any speaks about a pr oject management approach. Whether this approach is full DoD IMP/IMS down to someone claiming to have "magic beans." The method must ask and answer...

• How long are you willing to wait to find out you're late, over budget, or not on technical specification?
• What are you going to do to get back to some place that is acceptable to all the participants?
  

If your magic beans or your DoD FAR 15.2 procurement process can't answer these questions in some unit of measurable meaningful to the all the participants - you're not doing project management.

PMI Scheduling Professional

    At the PMI College of Scheduling conference, May 4th - May 8th in Chicago, a Scheduling Professional Credential is being introduced. The conference speakers address the issues around project planning and controls, scheduling, programmatic risk, performance measurement baselines, and integrated baseline reviews. Focused mostly on construction, but with aerospace and defense and some comparisons between construction and IT, the conference represents the current opinions of how to create, manage and deploy project scheduling processes.
    My paper is title  Establishing the Performance Measurement Baseline

The Performance Measurement Baseline (PMB) is a time–phased network of schedule activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables from this work, and the performance measures showing this work is proceeding according to plan. For enterprise projects, the PMB provides the needed insight, cost controls, and business value tracking that assures the successful outcome of the project for both the provider and consumer.

The PMB is the baseline of the cost, schedule, and deliverables for each WP in the plan. The sequence of completed deliverables describes the increasing maturity of the capabilities produced by the project. Constructing the PMB depends on knowledge of the business requirements, skill in developing the WPs that produce the deliverables for these requirements, and discipline in assembling the cost, schedule, and relationships between the WPs. It is this discipline that requires the most focus for the planners and project controls staff. Without this discipline, the development of a credible baseline is simply not possible.

Copies will be available after the conference.

Sacred Cow: Teams

    The comments from the "Killing the sacred cows of project management" post brought some heat (not much light yet) to bear on the approach of "knocking out" thoughts in a blog.

Teams
    So here's the first topic a bit more depth.
    It is very popular these days to consider "teaming" and "teams" as the approach to all project management problems. Trouble is there are missing elements in this approach:

• Of the members of the Team, who is the leader?
• Who is accountable for the teams outcomes?
• How is the team directed?
• Is it self directed?
• Is it self organized?
• When the team is doing the work they have been assigned, or somehow become accountable for, how is this performance measured?

The Katzenbach book The Wisdom of Teams was (and still) is popular. Having used this book to construct agile (XP) teams in the mid-90's, one of the sacred cows is that "teams know best." Here's some troubles with that concept in the project management world:

• If the team is collectively accountable for the outcome, where does the role of "leadership" come into place?
• How can the "collective" be held accountable?
• Is there such a thing as collective accountability?

Notice accountable is not the same as responsible. Accountable is a single source concept.
    Next comes the question of how does the team get its direction? Externally or internally? This can be sorted out when the team is chartered. Here's what has worked in the XP and CMMI world:

• Charter the team with two external interfaces:
  • Score keeper
  • Spokes person
• Find someone externally to hold accountable for the actions of the team. Having a collective accountability leads to the lowest common denominator of accountability.

We learned the hard way the "self directed" is not the same as "self organized." Once given clear, concise, and measurable direction, the team could organize to deliver on that clear, concise, and measurable direction. In the absence of this, the team tended to become "self managed" and got off track very quickly. The role of management in a "team work" environment is to provide guidance for the team. In the same way a quarter back for football, setter in volleyball, captain in cross country, and catcher in baseball. They are a team, but also have an identifiable and accountable leader.

Now the Bigger Question
    Do teams produce better ideas than individuals? Good question. Those who hold teams as a sacred cow conjecture that teams always produce better ideas. But here's the BIG missing point for those "sacred cow holders."

Teams and team work are not the same.
You can have team work in the absence of Teams. Teams may have poor team work within the team, as well as external to the team.

A colleague once stated - and I was not too favorable at the time, but have got religion...

I want one neck to wring

Who is that? Can you name a name?
Caution
    This post is not a tutorial, journal paper, or conference presentation. It's an opinion derived from 30 years of being a member of and managing projects. While possibly controversial in some circles, I've come to realize the project management profession holds many sacred cows - unassailable perceived truths - that need to be tested once in awhile.

The Best PM Book I've Read So Far

    I read lots and lots of project management books. Ranging from useful to nonsense. This one's both useful and makes sense.

Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation, Aaron J. Shenhar and Dov Dvir, Harvard Business School Press, 2007

    This book has sensible, realistic, practical suggestions on how to manage projects. No "magic beans," no psycho-babble about self actualizing the staff before starting to manage the project, no over the top agile suggestions about the lack of purpose of project management, self indulgent proclamations about having discovered the secret to managing projects in some new paradigm, so suggestions that we know and apply every day is some now obsolete. Just plain, straight, approaches to delivering value to customer.
    Worth the $35, buy it, read it, read it again, get back to the work of managing projects for money. That's what we get paid for, that's why we're called project and program managers. We do (or should) deliver value to customers.