The Regenerate Web

My friend Jack is sometimes a bit forward, but he has a point when he posts a comment on Andrew Filev's PM 2.0 blog. 

Notional charts are just that notional. Not the basis of decision making.  Jack is a very seasoned project manager, and like me the suggestion that a technology (Web 2.0 and it's cousin PM 2.0) is the basis of something new in the project management space is, how can I say this, not credible. 

Having been in the technical and business software development, enterprise IT, and related technology business since the late 70's, I've seen a several dozen or so "next new things," ranging, from the first structured programming languages - Pascal and its father Algol-68 to the savior of the western world ADA, the Saviour of all things networked SNA and then of course TCP/IP, anyone remember XNS, much better than TCP/IP, but like all things Xerox too complex and proprietary. To the introduction of mini-computers - I wrote me first Fast Fourier Transform (FFT) algorithm in a PDP-8M with 4K of memory. Ran at a blazing 120KHz for 128 point "real" number sampling buffer. To the demise of COBOL. I actually tried to carry Grace Hoppers bag, when I picked her up at the Orange County airport for an ACM meeting. She sternly stated to me in her Navy Captain's uniform, "young man I am perfectly capable of carrying my own luggage." To time sharing - Boeing TCS were APL wa our language of course for radar signal processing simulation. To the Lisa - I acutully wrote code for that beast.

All of this is the lay the ground work for Jack and others, that we're skeptical of "revolutionary solutions" to what is essentially an ancient problem - managing projects. I draw my recent skepticism from a solid business book, introduce to me by Bill Duncan, of PMBOK 1996 fame - Beyond The Hype: Rediscovering the Essence of Management, Eccles and Nohria, Harvard Business School Press, 1992. 

Yes 1992, when the same approaches to "new idea" introduction were being written about then are reappearing now. The issue for Jack and those like him - including me - is that the term Project Management has been relabeled to mean the technology of a small portion of manging project management - the interpersonal communications and people collaboration part. 

Once that relabeling has been introduced the Essence of Project Management, like Eccles's "essence of management," is lost and the pitch becomes "look at my shinny new idea." Which is not a idea or process per se but a product that has been labeled as Project Management, PM 2.0.

So if we want to talk about the Real PM 2.0, how able a solution to the abysmal success rate of enterprise IT. Or the equal abysmal success rate of DoD projects. DOE seems to have some secret sauce. Or that $4B write down at the IRS. Or the $3B "gone missing" for the World Wide Command, Control, and Communications System back in the 80's. Or the in the news today where the video link on the Predator can be hacked. The Information Assuance (the new term of encryption) guys needs to be taken to the wood shed.

PM 2.0 needs to search for actionable improvements in the processes used to actually manage projects. Where management is a verb not a noun.

The selling of PM 2.0 is a product approach to what is essentially a people and process problem. It's a one legged stool in a four legged table world.

Steve posted a comment on a previous post that spurred me to put on my physics and systems engineer hat for a moment.

The power law notion presented in the previous post by Andrew Filev is useful in many domains.

The Power Law is applicable IF, one quantity is dependent on another raised to a "power." What Andrew did was to assume this is the case then build an example. In the statistics world this is called a Post-Hoc argument. It goes like this, "Let's assume there is a power law relation between the number of small (no defined unit for small) and large (no defined unit of large) and possibly mega (again no defined unit) then the "power law could be tested - not assumed post-hoc.

Here in the space and defense business a "notional" concept is used all the time. But the little joke is "I see you're making a notional description of the problem at hand, nice power point presentation, where's the real numbers?" The classic is the Power Point pictures of flying to the moon, then to mars in the 500 page backgrounder called Constellation, were one of the programs we work derives the Orion manned vehicle avionics, which will go to the Space Station in 2014 (maybe), From there it's only a 1,000 times scaling to get to the moon and only a ½ million times scaling to get to Mars. No problem, we got a nice PPT picture of how to do it.

Now to the subject long tails in task durations

Steve asked about long tails for task durations. Great question.

The use of Mote Carlo simulations is mandated in our domain (DID 81650 is the source document). The tools we use (Risk+ and @Risk For Project) provide probability distributions that can be tuned for the specific task modeling. There is a principle in this practice that say "any longer than 35% or so to the right requires management intervention, don't use that in your model."The triangle distribution is usually the starting point. The boundaries of the Triangle in Risk+ are the 0 and 100 end points, in @Risk they are the 10% and 90% end points. This provides the ability to describe an asymmetric shape for the task durations.

But, and this is critical, the "long tails" don't exist in the planning process. Independent of their possible existence. This is the role of the Integrated Master Plan - to reduce the probability that there are "unknowns," in the plan. The real long tails - the unknown unknowns have been addressed in previous iteration of the program - during Milestone A and Milestone B. The work of system development - Milestone C - is working toward the low rate initial production.

The second rule - in our domain - is you plan and mange at the Work Package level, not the task level. Task management is the accountability of the Control Account Manager, or her designated Work Package Manager. Work Packages con only cross one accounting period. These means they are limited to 60 calendar days. Like Vegas, what happens inside the WP says inside the WP. It's the measure of physical percent complete we're after.

The reason for this is the WP is on baseline and if the tasks need to be rearranged for what ever reason - good or bad - we don't want to impact the baseline - 'cause there's too much paper work and we're essentially lazy. 

Power Laws Abound, But Make No Assumptions Without a Test

Power Laws describe relationships that are "scale independent." Physics is one place to start. Having grown up in the particle physics world, power laws are used in the Standard Model of particles. As well a REALLY good power law in classical physics (thermodynamics) is the cooking time of a turkey. It is a power law related to the surface area of the bird.

There are Power Laws in Economics, in biology related to ecological complexity, power laws everywhere.

So in the end- yes power laws are real IIF (if and only if) there is a exponential relation between one variable and another. Assuming there is first without a basis for that assumption and then making an argument (in the mathematical sense) about something is simply bad math.

The common approach in some domains - like this example - is to use a notional graph - Kent Beck did this - to make a point. But the point may not actually have a factual basis. It's a notional point. An interesting dinner conversation piece. But trying to make managerial decision from notional graphs is real sporty business where I work.

Your mileage may vary

"This musing, you describe, your first step in the planning process. How do you carry it to the next steps of planning? How does it help?" I asked.

"That's why it's so helpful. I used to sit down and start setting goals, but I gotta tell you, if you don't know where you intend to go, you don't know if a goal will keep you on track or lead you astray," Lauren began. "Some people call it, creating a vision. And that's fine if you are a visual person. But my musing about the future contains visual elements, sounds, smells and feelings. When I begin talking with my team about where I intend to go, I have to be able to touch everyone in the group in a way they can see it, hear it and feel it."

Paul Solomon has posted a link to the DoD Earned Value Management: Performance, Oversight, and Management Report to Congress. 

Anyone interested in the least just "favorite" Paul's site and subscribe to his posts. Paul's book Performance Based Earned Value, is heavily yellow highlighted and "tabbed" in my backpack everywhere I go. You can't really say you're an EV junkie unless you have his book.

The Projects@Work site has an editorial titled "Agile, by any other name." (Registration required). There is of course the original Agile Manifesto. Then 7 additions clarification points:

• Develop in short cycle times
• Plan short term (the next cycle)
• Develop only what is needed
• Close collaboration with the user
• High visibility and daily reporting
•  Empower the project team
• Test in parallel with development

These approaches are also found on large space and defense programs. There the Integrated Master Plan / Integrated Master Schedule (IMP/IMS) paradigm is mandated for programs greater than $20M. $20M sounds like a lot, but in that domain it's not. Most firms then push this paradigm down onto all programs. As well DID 81650 is mandated along with an Earned Value Management process.

Using the Agile Guidance for Managing Projects

While the 7 items above are usually applied to software development activities, they are generally applicable to any project domain and context. Here's how they are applied on 1/2 billion dollar manned spaceflight software programs, multi-billion dollar Army combat systems and many multi-billion dollar Air Force integrated world wide "everything over IP" program.

• Develop in short cycle times - the primary role of this behavior is to ask and answer the question. How long are we willing to wait before we find out we're late?

• Plan short term (the next cycle) - rolling waves are used for all non-trivial programs.

This means the current rolling wave is being executed from the Performance Measurement Baseline (PMB). The PMB is a time phased description of the cost, work, and deliverables. The current rolling wave consists of Work Packages, with a duration, resource "spreads" and a single deliverable.

Planning packages are used for "out year" (yes years) work. These Planning Packages has durations and cost spreads, since the the critical path must be identified from Contract Award to Contract Closeout.

• Develop only what is needed - the rolling wave work package process defines explicitly what is to be produced.

In the federal contracting world if you work on things that are not needed for the next Program Event - see Integrated Master Plan / Integrated Master Schedule Preparation and Use Guide - you wouldn't get paid.

It is critical for the program to work on only things that increase the maturity of the deliverables "as planned" in the Integrated Master Plan (IMP). Otherwise the program is decreasing the probability of success. There is an urban myth that programs like this have Big Design Up Front. That is simply a lie, er "red herring." Change is constant in Pre-Milestone C programs. These are System Development & Demonstration. The milestone after that (D) is Low Rate Initial Production (LRIP). SDD is emerging requirements driven.

• Close collaboration with the user - this is not as easy as in small team IT projects.

But Technical Interchange Meetings (TIM) occur frequently for all the obvious reasons - emerging requirements. As well there is daily if not hourly contact with the customer for SDD style programs for again all the obvious reasons. But requirements are flowed down from the customer to the supplier. There is more formality in the development and management of these requirements. This is driven by the production mature of the products. If you're building a one off is a test vehicle in a DARPA style program (a science project), the requirements management is much different than if you're upgrading all the F-18's in the fleet with new GPS navigation systems.

IT projects are almost always "one offs."

• High visibility and daily reporting - well maybe not daily, but certainty weekly.

•  Empower the project team - teams work as "teams." usually with a lead and a collaborative staff.

• Test in parallel with development - test driven development is the standard system engineering approach.

Recently, I had to undergo knee surgery for a torn meniscus (one of the indicators of age... sigh).  My surgeon was kind enough to give me a prescription for a pain killer, the generic version of Vicodin.  I was very careful to limit my use of the prescription meds, limiting it only to night-time.  However, a couple of days after the prescription ran out, I found myself getting jittery and anxious.  My body was coming off of a pain-killer dependence.  (And, no, I did not renew the presciption... after a couple of days the symptoms went away.)

Our systems sometimes go through detox as well.  Have you ever downsized an employee, only to realize how critical they were to your organization?  What about software or a policy that was tossed out?  When you remove a critical input (either accidentally or purposely), you run the risk of sending your system into detox.  It's become dependent on the input.

Sometimes the input is negative, but it still sends your system into detox.  Our perceptions, experiences, beliefs, and paradigms can be negative inputs into our system.  I found a great example of this over at the TiE Leadership program blog:

Sean O’Malley runs The Quarry, a business incubator at Venrock, a leading venture capital firm. In the last 18 months he has started 6 companies that have gone from blank slate, through “ideation”, execution and validation to receive Series A funding. He spent more than an hour talking with TLP Fellows about the “Idea Development Model” he uses.

It is important to take the time to do ideation right. The first thing I do when an entrepreneur comes in to The Quarry is put them through “detox”. 9 times out of 10 this is the best thing they have ever done. It is great to be able to take that step back. It should take a least three months, which may seem too long, but the idea forming stage is really the only time you'll have time!

Think about your systems.  What inputs would send them into detox?  Is that what you want?  How will you get your system back on track from the input withdrawal?

"Since you feel so strongly about this part of the planning process, tell me more about your musing?" I asked.

"Some people get stumped by starting on the wrong foot," Lauren explained. "They sit and try to think of all the things they could do. My problem is that, as fast as I can think of something I could do, I can also think of about five reasons why it's not possible."

"Yes," I replied. "One of your strengths is to anticipate obstacles before they occur, so we can take evasive action early. Tell me how you keep your mind from killing your ideas before they can take off. It must be a struggle."

"That's the thing. I don't struggle. I just skip it," she continued.

"Skip it?"

"Instead of trying to figure out what I could do, I just skip to the end, to where I have already completed the goal. And with that goal already accomplished, I simply imagine the world, then. And as I imagine, I ask myself if that is the world I intended to create?"

The last several posts have been around PM 2.0 and what that means, if anything to the project management space. It's time to remind all those claiming to have the next big thing in project management of the core elements of a success project.

First let's look at the sources of project failure. There are many of course. My particular point is view is from the Program Planning and Controls paradigm. There are numerous, probably too many to count reasons on the "softer" side of projects. And likely as many Tools reasons. .While people are certainty the most important aspect of a project, the tools are a distant 3rd for reasons mentioned in the past.

Let's look at the process needed to keep a project on track. Or another view, what things can derail a project.

Let me Count the Ways

• Inattention to budgetary responsibilities – if you're not watching the money, you'll run out and not know it. I've heard in the past that budget is not watched on many projects. I suspect this may be the case in immature organizations. But ask this. "do you watch your budget?" If you live pay check to pay check, you're implicitly watching your budget. Then why on God's Green Earth would you not watch the budget on a project. Especially if it was someone else's money?
• Work authorizations that are not always followed – as a project team do we work on anything we want to work on at any time we want to? Hopefully not. Working on the right things in the right order is part of project management.
• Issues with Budget and data reconciliation – when we're working on something, do we know how much we're spending? How much did we plan to spend? Do they match in any way?
• Lack of an integrated management system – an integrated management system could be 3x5 cards on the wall or a full blown SAP program management enterprise suite. Doesn't really matter in principle. But have something. Don't show up evey morning wondering "what should I work on today?" "What did I get done yesterday?"
• Baseline fluctuations and frequent replanning – are we bouncing all over the place when it comes to cost and schedule? "today it'll take 3 weeks to finish." "Nope, today it'll take 6 weeks." "Next week we discovered it'll take 12 weeks." Come on guys how ling is it going to take and how much is it going to cost. These number by the way estimates. They need variances and confidence intervals in order to be credible.
• Lack of predictive variance analysis – if I can't forecast future performance in some way, it'll be hard to tell when we'll be done. Agile uses velocity. Big programs use Earned Value. Use something. Don't just sit there and look stupid when asked "any guess about when we'll be done and how much it'll cost when get there?"
• Progress not monitored in a regular and consistent manner – "how we do'in?" "Oh I don't really know, we're taking this one day at a time." That's a possible answer for some situations, a death in the family, a recovery from illness, or a 100 mile loop on a road bike around the Colorado mountains. But probably not a good response for a project manager. Know how you're doing. Know that of you keep going at the rate you're going you'll arrive at some projected time. Just like looking at the speedometer on the road bike. "If I keep peddling at this rate, I'll arrive in Leadville in two hours."
• Lack of internal surveillance and controls – who's watching from the outside? Who agrees things are going according to plan. The notion that there is a plan is the first step. But let's assume there is a plan, who gets to say we're moving along according to plan?
• Managerial actions not demonstrated using performance measures – we discover we're late or over budget. Is there a management decision to do something about it? It doesn't have to be formal "management," but is there a decision by anyone to do something different. Or are we just containing blissfully down the road to the train wreck?

So now let's assume, and it might be a big assumption that we want to do something about this pending Train Wreck. What would we do?

Staying Out of the Ditch

Here's a set of answers taken for a large set of answers. The larger set is the 32 criteria of ANSI-748B Earned Value. Now Earned Value is not being recommended here. But most of what's in the EV standard is about "good project management." Not actually EV.

• Decompose the project into manageable units of work held in the Work Breakdown Structure (WBS) that states what DONE looks like.
• Assign responsibilities for the accomplishment of the each element of work at the appropriate management level using the Organizational Breakdown Structure (OBS). Join these two structures into a Responsibility Assignment Matrix (RAM).
• Create a schedule which identifies the work activities, milestones, and their dependencies for each intersection in the RAM connecting accountability with deliverables. Adhere to the schedule – last starts usually mean late finishes.
• Assign resources to the activities, determining the cost of these resources, producing the time phased budget for the project. The result is knowledge of who is accountable for the deliverables and what is their budget?
• Identify the objective measures (physical percent complete is preferred) for all the identified work – what does DONE look like and how are you going to measure progress toward DONE in units meaningful to the project?
• Establish a change control procedure for the Performance Measurement Baseline (PMB) – assuring changes don't unfavorably impact the plan.
• Formally release the work packages for execution by the assigned resources during the planned period performance – do the work in the right order.
• Record and accumulate the projects progress through cost and schedule performance measure – assure you're measuring physical percent complete.
• Use the cost and schedule variances to develop an Estimate At Completion (EAC) and Estimates to Complete (ET) for all future planned work – use data to "manage."
• Take managerial action to compensate for past deviations or correct the planned work to meet the approved Budget At Complete (BAC) on schedule – "manage the project"
• Track and manage all changes to PMB. Past performance is a good indicator of future performance – knowing how you got to where you are now, helps knowing where you'll be going to be the future if you don't make corrections to your course.

Andrew Filev provided an interesting notion about the distribution of projects. This diagram was an anchor of the conversation.

Notionally is says the are more small projects than large projects. I use the term "notionally" for a reason. Here in the defense business\, a notional diagram is a nice Power Point picture. There is a notional picture of docking at the International Space Station (ISS) with the new Orion manned spacecraft. It will work eventually. But for now it's a nice picture of how it might work.

I did a bit of poking. There were $90.8 Billion in US Based firms for projects in the sectors (The 2009 Top US Design Firms, Engineering News-Record):

• General Building - General Building, Education, Commercial Offices, Retail, Government Offices, Health Care, Multi-Unit Residential, Correctional Facilities, Distribution and Warehouses, Hotels, Motels and Convention Centers, Religious and Cultural, Sports, Entertainment
• Transportation - Transportation, Highways, Bridges, Airports, Marine and Port Facilities, Mass Transit and Rail
• Manufacturing/Industrial Processes/Telecommunications - Industrial Process, Food Processing, Chemical Plants, Pharmaceuticals, Steel and Nonferrous Plants, Pulp and Paper Mills, Telecommunications, Transmission Lines and Cables, Data Centers and Web Houses, Towers and Antennae, Manufacturing, Electronic Assembly, Semiconductors, Auto Plants, Aerospace
• Petroleum - Petroleum, Refineries and Petrochemical Plants, Pipelines, Maintenance, Offshore and Underwater Facilities
• Power - Power, Nuclear Plants, Operations and Maintenance, Hydroplants, Cogeneration, Fossil Fuel
• Environmental - Sewerage and Solid Waste, Sanitary and Storm Sewers, Water Supply, Treatment and Desalination, Transmission Lines and Aqueducts, Dams and Reservoirs, Hazardous Waste, Chemical and Soil Remediation, Asbestos and Lead Abatement, Site Assessment and Compliance, Nuclear Waste, Clean-Air Compliance

That's Billion with a B. This is just for the "built environment," as those in that industry like to say. Another approach is to look at individual firms in our sweet spot - firms that are 100% or close project driven. For example Honeywell Aerospace is a $12.7B revenue in 2008. 90% of everything they do is a "project" or a "program."

The top 25 software providers in the world generated $160B in revenue. The Top 100 generate $202B in revenue in 2008.

Now let's take a pause. Out of this 202+90+some billions of revenue, how many projects do you think there are? I'd say lots. Now add the Federal, State, and Local "projects," from their published budgets. DoD is $513B, DOE $27, DHS $37B. So with all this it's around 202+90+513+27+37. Take away the operational aspects of the feds (down by half) and you get around 869 adjusted to say $500B. That's half a trillion dollars a year in projects. So what's the dollar of every small and personal project on the planet?

To move from a notional graph - which may or may not have any connection to reality - to something that is useful and possibly actionable, the dollar value of projects might be useful. As an aside, I'd think those in the PM 2.0 market place would want to know the total available market for their products.

But that comes from my limited experience of going through 2 start ups, one which made it to IPO, www.triconex.com.

So what does all mean in the end. Yes there are likely more small projects than large and many even medium. PM 2.0's sweet spot is in the small domain. But no one said what the size of a "medium" project is? $1,000? $10,000? $100,000? 

Then the graph makes that wonderful jump described in How To Lie With Statistics, Darrell Huff, 1954. And that is, show the number in a logarithmic scale. That jump from personal, to medium to Mega.

In the end this is a dimensionless, unit less, content free picture. Reminds me of the early Kent Beck concepts of the cost of change of XP versus conventional. Nice notional picture.

Worthless for making business decisions.