Herding Cats

The Dinosaurs Didn't See It Come

The Dinosaurs had their day in the sun. They also had a lot of trouble in the presence for emergent competitions. But they dominated our planet for 160 million years. The PM 2.0 advocates are sounding o lot like lifeforms saying "you're a Dinosaur, your days are numbered."

Like the extinction of the dinosaurs where there were transitional forms before the next dominate form took hold - small to medium sized manuals - the PM 2.0 has a lot to learn from that process.

Shouting PM 1.0 is dead and the traditional forms of process support is not a strategy to advance the species. To replace the previous paradigm, you must be able to improve the species. 

Since PM 2.0 is not based on "project management" principles it's going to be tough going for this transitional life form.

"There's no PM in PM 2.0!" Yes Dorthy, there is no PM in PM 2.0. Lot's of virtual communication, lots of user configured tools, lots of cleaver gadgets on your Blackberry and iPhone for tweet each other about what's happening on your projects.

Where's the Performance Measurement Baseline? Don't want one of those, OK, where's the configuration controlled master schedule. Don't have one of those, OK where's the Scrum feature backlog for everyone on the team to stand in front of during the morning sprint meeting to see what we're going to work on today, this week, this sprint.

If you don't have a Performance Measurement Baseline, then who on your team knows what the planned completion date is? No completion date, then this effort is probably more like level of effort maintenance than a project - which by definition has a planned end date.

"Anybody around here have an idea what this will cost when we're done?" No, I'm sure the person with the check book is real happy about that. 

How about we tell someone what kind of progress we're making and how much it costs to make that progress and with that "burn" rate when we will run out of money or time or both?

You see there is no "there, there" when PM 2.0 is spoken. No fundamental principles of "managing." No practice areas. No knowledge groups. No nothing other than the hype of "the next new thing."

Now granted of your project is a gardening project. Or you park your project on a Blog, then PM 2.0 is right up your alley. PM 2.0 has a very strong genetic connection of social media. Emergent rules, content, and results. Great stuff. But as the Program Manager for the current manned spaceflight effort asks every Monday morning at 6:30AM

When's this thing going to fly?

Don't know? Find me someone who does and don't let the door hit you in the ass on the way out.

A project has a schedule, a budget, a set of technical and operational performance goals and has some way to measure physical progress to the plan. Please someone point me to where I can find those things in the PM 2.0 swamp?

Why the Performance Measurement Baseline is the basis of project success

When I hear talk about the PM 2.0 attributes being the basis of project success, I get a smile on my face. Not because I agree, I don't. But because words like..

Project Management 2.0 is an approach to managing projects that is brought to life by the use of Web-based, emergent, collaborative project management software and that focuses on collective intelligence, productivity and project leadership as the basic factors of project success.

...are so disconnected from the actual processes and attributes that are the basic factors of project success. As well these attributes are "restatements of the obvious." Projects that don't ...

• Use Communication is an enabler of project success. Without good communication projects fail. What "done" looks like, how to plan the work to move the project forward requires communication. Communication about the commitments and promises to deliver the intermediate products and services. Communication about what those products and services are and their units of measure for progress.
• Provide collaboration is critical to all the participants on the project. What to collaborate on. How to perform the collaboration process. What are the results of this collaboration.
• Improve productivity, is a tautology, without productivity the project is behind schedule and over budget. But what are the planned measures of productivity needed to reach the end on-time, on-budget, and on-specification
• Assure leadership, of course is a tautology - another restatement of the obvious. Leadership on projects takes many forms, likely dependent on the domain and context. Leadership on a web based development project for a a local retailer is likely much different than leadership on a multi-billion dollar defense program.

So now what? How can the probability of project success actually be improved with actionable outcomes?

The presence of these attributes says nothing about the project itself, what "done" looks like, how to get to "done," how to measure progress along the way to "done," and most importantly what are the impediments to reaching "done," and the mitigations and retirements of these impediments.

Here's one starting point for increasing the probability of project success.

Increasing The Probability Of Success For Your Project

View more documents from Glen Alleman.

Quote of the Day

Our brains have evolved (enough) to get us out of the rain, find where the berries are and keep us from getting killed. Our brains did not evolve (sufficiently) to help us grasp really large numbers or to look at things in a hundred thousand dimensions.

— Ronald L. Graham - Mathematician

Quote of the Day

The further backward you look, the further forward you can see
- Winston Churchill

Those talking about the "new" generation of project management (PM 2.0) processes will be well advices to come fully to terms with what the conventional approaches have to say. These include the immutable processes of managing a project that are independent of any tools, version 1.0, 2.0, or any.0.

• What is the estimated cost of this project when it is done?
• When are we forecasting it will be done?
• Can we say with some level of confidence that the business case will be met?
• Are there any impediments to reaching done? If so, what is the plan to have these mitigated or retired?

The answers to these and other questions are contained in the cost, schedule, and technical performance baseline. This baseline is a conventional approach to managing the project. It "says" what is planned to happen, what is the outcome of the work, and how this work will be measured against the planned increasing maturity of the product or service.

In the absence of the processes that answer these questions no amount of cleaver PM 2.0 is going to increase the probability of success of a project.

The Whole Brain Look at Project Management

In Rechtin's Systems Architecture book, there is a list of what makes a good system architect. The system architect he speaks of is not the IT architect - although in the 2nd edition, he includes that. It is the product architect. Products like GPS, the Space Shuttle, complex military and civilian systems.

A recent paper in the INCOSE Systems Engineering Journal, revisits this concept. "Whole Brain Thinking in System Architecting," Tony Di Carlo, Behrokh Khoshnevis, and Firdaus Udwadia, Volume 13, Number 3.

I'd conjecture these attributes can be found in good project managers as well:

1. Communication skills 
2. High tolerance for ambiguity 
3. The ability to make good associations of ideas 
4. The ability to work consistently at an abstract level 
5. A level of technical expertise 
6. A tempered ego; the opposite of arrogance 
7. Leadership; gets the most out of others 
8. The willingness to backtrack, to seek multiple solutions 
9. The ability to build teams 
10. Charisma 
11. The ability to read people well 
12. Self-discipline, self-confidence, a locus of control 
13. A purpose orientation 
14. A sense of faith or vision 
15. Drive, a strong will to succeed 
16. Curiosity, a generalist’s perspective

So now, assuming my conjecture is applicable, where do tools fit into the discussion of increasing the probability of project success?

How Many SW Projects Have No Concern About Budget or Schedule?

Rob Schneider posted a comment suggesting the PM 2.0 proponents "are people (that) tend to have experience/careers in industries and on projects where scope is fungible."

I'm wondering out loud how many software projects have these attributes. I have no experience in that domain. I've experienced firms that hired us to rescue projects where they started out that way. Product companies and internal IT development efforts (mostly ERP).

But could it be that PM 2.0 is targeted to "projects" where the scope has no bounds and therefore the budget doesn't either. Brian Kennemer says the budget controls are rare on the projects he helps. 

Is these actually the case over the broad spectrum of software development activities. There are 36 NAICS codes for "software." The 541XXX section is for development. I'll poke around to see what amount they contribute to the GDP. 

Maybe all this fuss about the applicability of PM 2.0 is moot. Maybe the number of firms that don't care about managing cost, schedule, and technical performance in ways similar to PMBOK is trivially small.

So here's a quick summary from the Bureau of Labor Statistics for the 541500 NAICS code (Computer System Design and Related Services), by subcategory and number employed as of May 2008

• Computer Programmers - 394,320 
• Computer software engineers, applications - 494,160 
• Computer software engineers, system - 381,830 
• Computer systems analyst - 489,890
• Data Base Administrators - 115,770
• Network and Computer Systems Administrators - 327,850
• Network Systems and Data Communications Analyst - 230,410

When you add in the other ancillary occupations related to computing systems you get 3,308,260 people working in the Computer and Mathematical Sciences Industry.

So which of those 3,308,260 have some concern for staying on budget and schedule? How can PM 2.0 processes as described in this post help them do this?

Now add to those, the other "project" based activities - construction, product development, industrial operations, and similar labor codes and ask how many "projects" can:

use Web-based, emergent, collaborative project management software and that focuses on collective intelligence, productivity and project leadership as the basic factors of project success?

Rather than a credible Performance Measurement Baseline with proper project controls to avoid the root causes of project difficulties described by:

• Inattention to budgetary responsibilities
• Work authorization not always followed
• Budget and data reconciliation issues
• Lack of an integrated management system
• Baseline fluctuations & frequent replanning
• Current period and retroactive changes Improper use of management reserve
• Performance measurement techniques not reflecting actual accomplishments
• Untimely and unrealistic Latest Revised Estimates (LRE)
• Progress not monitored in a regular and consistent manner
• Lack of vertical and horizontal traceability (critical path)
• Not capturing and using cost and schedule data for corrective action
• Lack of predictive variance analysis
• Lack of internal surveillance and controls Managerial actions not demonstrated using Earned Value (or some form of performance assessment)

Quote of the Day

Their judgement was based on wishful thinking than on sound calculation of probabilities; for the usual thing among men, is when they want something, they will, without any reflection, leave that to hope; which they will employ the full force of reasoning in rejecting what they find unpalatable.

— Thucydides

Can this realy 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 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 every 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 under side 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 fr 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 "data base," 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, next deliverables, next rolling wave. These process 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 work stream managers, the Program Planning and Controls staff, the Program Manager and his deputies. There can't be successful 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 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, specialized enterprise tools like wInsight. All collaborative web-based tools 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 tool sets. 

Quote of the Day

Principles that are established should be viewed as flexible, capable of adaptation to every need. It is the manager’s job to know how to make use of them, which is a difficult art requiring intelligence, experience, decisiveness, and, most important, a sense of proportion.

- Henri Fayol3

Can PM 2.0 Cure the Common Problems with Troubled Projects?

In a response to the new definition of PM 2.0, it was stated

Project Management 2.0 is an approach to managing projects that is brought to life by the use of Web-based, emergent, collaborative project management software and that focuses on collective intelligence, productivity and project leadership as the basic factors of project success.

It turns out from research there are a common set of attributes found in troubled projects:

• Inattention to budgetary responsibilities
• Work authorization not always followed
• Budget and data reconciliation issues
• Lack of an integrated management system
• Baseline fluctuations & frequent replanning
• Current period and retroactive changes Improper use of management reserve
• Performance measurement techniques not reflecting actual accomplishments
• Untimely and unrealistic Latest Revised Estimates (LRE)
• Progress not monitored in a regular and consistent manner
• Lack of vertical and horizontal traceability (critical path)
• Not capturing and using cost and schedule data for corrective action
• Lack of predictive variance analysis
• Lack of internal surveillance and controls Managerial actions not demonstrated using Earned Value

So an open question to the "leading voices" of PM 2.0.

How can PM 2.0 address these problems (or other identified problems for that matter) in specific ways in order to increase the probability of project success?

Managing By Exception

PM Hut has a post on Managing By Exception. While the concepts posted there are good in "principle," in "practice" more needs to be in place to keep the project on track.

First there needs to be a set of clearly defined assessments of physical percent complete. Along with that some means of assessing the increasing maturity of the products or services produced by the project. And of course some type of "exit criteria" for each Unit of Work produced by the efforts of the project team. Finally, a means of identifying, handling, and reporting the risks to the progress of the project.

In the absence of this information, there is no raw material available to assess the exceptions. Only when the Plan, Schedule, Risks, and Measurement processes are in place, can the exceptions be determined. Having the Project Manager track and reviews but does not intervene only works if the "control boundaries" are defined in units of measure meaningful to the stakeholders.

As well the statement that "Management By Exception" is a relatively new concept is likely not correct, unless "new" means defined in the last 100 years. MBE is the basis of military command and control for small unit engagement. It was applied in the aerospace business in the late 70's.

petitio principii

petitio principii is "begging the question. To beg the question is to assume as true the thing that you’re trying to prove.

Disputing this claim is not an argument against the existence of the idea being disputed. It is entirely possible for the idea being disputed to be true. But it is not even wrong to claim that we know that the idea is true because we say it is so. A statement constructed in this way is not an argument. It is meaningless.

This approach is common in many discussions about processes associated with project management.

What happens in most instances is a conjecture is made in the absence of a domain and a context within that domain. For example, the governance processes used to run the IT department of a major western city are much different than the governance processes used to run the local grocery chain here in Boulder Colorado.

So discussions about the applicability of change control need a domain and context. In the absence of the domain and context, discussion is meaningless.

Another example is where to place the earned value controls on a large project. A self proclaimed project management heretic asserts that only fools don't manage EV at the lowest level of the project. At the Task level. As an aside this same self proclaimed heretic works for companies where there are 10's of 1,000's of tasks that have to be updated and transferred to the cost system for the projects he works. 

That aside, the 10's or 1,000's of PP&C analyst working EV project every day in the US Department of Defense manage the program at the Work Package level, not the Task level. The CAM (Control Account Manager) is accountable for reporting the physical percent complete of the Work Package from the individual tasks.

Until the discussion around the very real problems of project and program management start with a context and a domain and make use of a set of immutable set of project management processes, much of the conversation is just noise.

PM 2.0 version 2

There's a new definition of PM 2.0

Project Management 2.0 is an approach to managing projects that is brought to life by the use of Web-based, emergent, collaborative project management software and that focuses on collective intelligence, productivity and project leadership as the basic factors of project success.

Ignoring for the moment if you took out the Web 2.0 words, this would a good description of any modern PM method. So let's look at the product offerings of some mainstream players and test then against the PM 2.0 definition.

• Safran North America
• DelTek
• Oracle Primaveria
• SAP / Dassian
• Microsoft Enterprise Project Management
• A bunch of SharePoint MOSS add ons for Microsoft Project like EPM Solutions

With the new PM 2.0 definition and these tools we see they are for the most part web based - all of which I have hands on experience with in a variety of business domains. They have attributes in common with PM 2.0, if you look at the Wikipedia definition of Web 2.0

The term "Web 2.0" is commonly associated with web applications which facilitate interactive information sharing, interoperability, user-centered design[1] and collaboration on the World Wide Web. Examples of Web 2.0 include web-based communities, hosted services, web applications, social-networking sites, video-sharing sites, wikis, blogs, mashups and folksonomies. A Web 2.0 site allows its users to interact with other users or to change website content, in contrast to non-interactive websites where users are limited to the passive viewing of information that is provided to them.

Each of these firms in the list above would say they have Web 2.0 offerings,per the definition above - especially MSFT. Some actually have it more than others of course. But the PM 2.0 attributes like...

• Web based, yep all are web based for the simple reason that Fat Client are too expensive
• Emergent "something"
• Collaborative project management
• Focused on collective intelligence
• Productivity (who doesn't have that in 2009 offerings)
• Project leadership, what ever the units of measure that is

...are stated to be the basic factors of project success.

If it is true that the items above are the basics of the success  of a project, then is it likely everyone should toss out PMBOK, the DoD Probability of Project Success guidelines for each service, all the Earned Value Management Systems Descriptions, all the IMP/IMS guidance in the Federal government (DID 81650 for example), all the project management process handbooks developed from CMMI-DEV 1.2, NQA-1 (nukes), the DOE 413.3 series (DOE capital construction and operations), all the risk management guides, SOX, ITIL... OK, you get the point.

The items listed above as the basic of project success are NOT, I repeat NOT, the basic factors for project success. That is utter nonsense. Forget the "no moral motivation" argument. This conjecture follows Wolfgang Pauli's statement about a paper submitted to him for review by a physics student.

This is not only wrong, this is not even right

OK I'll give the PM 2.0 people the last one - leadership. Oh all right, collaborative behaviors in project management is critical. But behaviors don't need fancy tools, just collaborative people. Which by the way are explicitly called out in PMBOK and every government agencies PM handbook.

Here's a book chapter that "may" shed some light on the basics of project management in the context of "agile." Figure 1. is one of many taxonomies of the elements of project activities required for project success. Figure 2. is a recent survey of the primary sources of failure in software projects. And Figure 4. is Capers Jones' software taxonomy. So what is the PM 2.0 sweet stop?

Just to round this off, here's a survey from Marios Alexandrou on project management methods. Some should be considered software development methods, but for sake of argument, let's consider than all PM methods for the moment:

• Adaptive Project Framework
• Agile Software Development
  
• Crystal Methods
• Dynamic Systems Development Model (DSDM)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Information Technology Infrastructure Library (ITIL)
• Joint Application Development (JAD)
• Lean Development (LD)
• PRINCE2
• Rapid Application Development (RAD)
• Rational Unified Process (RUP)
• Scrum
• Spiral
• Systems Development Life Cycle (SDLC)
• TenStep Project Management Process
• Waterfall (a.k.a. Traditional)

So now if we connect the project management methods, the Knowledge Areas and Process Groups from PMBOK, with the project management tools, we get a nice dense matrix. In this constructed matrix I'm hard pressed to see how the attributes listed above for PM 2.0 have much to say about "increasing the probability of project success." Which by the way has a specific definition in the context of large projects.

If anyone can connect the dots for me, I am my PM 1.0 colleagues will be humbled to learn what we're missing out on in the PM 2.0 paradigm.

Lazy Project Management?

PM Hut has a post about "lazy management." The idea that the PM reads the morning paper, chats at the coffee machine and generally "hangs around" watching people work is likely VERY domain and context sensitive.

I would be dumb struck to see the project manager for the recent I-25 rebuild by Kiewet Construction. Or the project manager for Building 777 at Rocky Flats, or the project manager for a $170M ERP integration at a health insurance company. Or the best example of the Program Manager for the major manned space flight program.

On those programs, the PM is not "running around with her hair on fire," but it is unlikely there is a spare minute in the day. As well the alternative is not to micromanage the work of others. Instead all project participates "execute the plan," in a manner appropriate for the scope and critically of the project. The more critical the project, flying to the moon, the more likely everyone is running at 110%.

If the project is a casual endeavor, then "lazy management," may be the norm. The notion of "managing" the project at the people level by the direct contact is also unlikely in critical projects. The work management is done through "work packages," with defined deliverables, measures of performance, and risk adjusted costs and schedule.

So where is "lazy project management" appropriate? Good question?

Lazy Project Management?

PM Hut has a post about "lazy management." The idea that the PM reads the morning paper, chats at the coffee machine and generally "hangs around" watching people work is likely VERY domain and context sensitive. 

I would be dumb struck to see the project manager for the recent I-25 rebuild by KiewetConstruction. Or the project manager for Building 777 at Rocky Flats, or the project manager for a $170M ERP integration at a health insurance company. Or the best example of the Program Manager for the major manned space flight program.

On those programs, the PM is not "running around with her hair on fire," but it is unlikely there is a spare minute in the day. As well the alternative is not to micromanage the work of others.

Instead all project participates "execute the plan," in a manner appropriate for the scope and critically of the project. The more critical the project, flying to the moon, the more likely everyone is running at 110%. If the project is a casual endeavor, then "lazy management," may be the norm.

The notion of "managing" the project at the people level by the direct contact is also unlikely in critical projects. The work management is done through "work packages," with defined deliverables, measures of performance, and risk adjusted costs and schedule.

So where is "lazy project management" appropriate? Good question?

Quote of the Day

When two opposite points of view are expressed with equal intensity, the truth does not necessarily lie exactly halfway between them. It is possible for one side to be simply wrong.

— Richard Dawkins, evolutionary biologist

My Six Honest Serving Men ...

Josh Nankivel is interviewed by a student from Help University College in Malaysia. One of Josh's statements rang a bell for me.

When asked, 

"What is the greatest challenge for you as a Project Manager?"

Josh said,

"The specifics depend on individual projects and their environment. In general, the greatest challenge is ensuring clarity of “what, when, who, why, and how” for everyone, including the customer, project sponsor, team members, and all external and internal stakeholders. Most project failures in my experience stem from a failure to do this."

This list of "questions" is from the Kipling Poem, The Elephants Child.

The answers to these questions must come from processes executed during the project. Here's my take on what those processes must be, taken from our process handbook.

There are 5 process areas used to answer the questions. 

Identify Needed Capabilities

Define the set of capabilities needed to achieve the program objectives or the particular end state for a specific scenario. Using the ConOps, define the details of who, where, and how it is to be accomplished, employed and executed. The ConOps (Concept of Operations) is a description of how the resulting product, system, or service will be used from the Point of View of the "customer." 

Establish the Requiremnets Baseline

Define the technical and operational requirements that must be in place for the system capabilities to be fulfilled. First, define these requirements in terms that are isolated from any implementation technical products. Only then bind the requirements with technology.

Establish the Performance Measurement Baseline

Build 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, and the performance measures showing this work is proceeding according to plan.

Execute the Performance Measurement Baseline

Execute work packages, while assuring all performance assessment are 0%/100% complete before proceeding. No rework, no forward transfer of activities to the future. Assure every requirement is traceable to work and all work is traceable to requirements.

Perform Continuous Risk Management

Perform the 6 process areas of Continuous Risk Management for each Deliverables Based Planningsm process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk.

At the highest level, these are the immutable processes needed to answer the Six Questions. This is a list of the "one true method" for managing projects, in the same way the Six Honest Serving Men, were Kipling's "one true method" for gathering the news while employed as a reporter in India.

There is more to managing projects than this of course. Along with the 9 Knowledge Areas and 6 Process Groups of PMBOK, any proposed project management method must address in some way, these items. In the same way as being a reporter is more than asking and answering Kipling's question.

In the end if you are not guided by these questions, the results will be disappointing to everyone, you, the customer, the stakeholders, and most importantly your ability to grow as a project manager.

Project Management Books

Andrew Filev asked on his Blog awhile back, "what Project Management books should you read?" This is a good question for all project managers. But I have difficulty with the books he listed. Which may be my same difficulty with grasping the notion of PM 2.0 paradigm. 

His first "book" PMBOK^® is not a "book" about project management in the sense of the books listed below. The PMBOK^® speaks its name. It is a Guide to the Project Management Body of Knowledge. The Knowledge Areas (Integration, Scope, Time, Cost, Quality, HR, Communications, Risk, and Procurement) and Process Groups (Initiating, Planning, Executing, Monitoring and Controlling, and Closing) in PMBOK^® provide a framework for managing projects. Which by the way, if you're not doing these knowledge areas and process groups in some way, you're not doing project management. You might be doing something else, developing code, collecting "to do lists" in your email, chatting with colleagues on IM and Twitter. 

So first of all, please do not use PMBOK^® as a starting place for learning about project management. PMBOK^® is a framework assessment book. 

Here's what's on my self that I use for our practice of Program and Project Management and Program Planning and Controls.

• The Management of Projects, Peter W. G. Morris, Thomas Telford, London, 1997. You can get this book from Amazon UK or sometimes from Amazon US
• AntiPatterns in Project Management, William Brown, Skip McCormick, and Scott Thomas, John Wiley and Sons, 2000. They have other AntiPattern books as well. Although Patterns and AntiPatterns have good out of favor in the ADD world of WEB 2.0, knowing these AntiPatterns will allow you to resist the siren song of IM, Twitter, and email as a replacement for good project management processes defined in PMBOK^®.
• Modelling Complex Projects, Terry Williams, John Wiley & Sons, 2002. All nontrivial projects are complex in some way. All attempts to simplify complex projects usually fail in some spectacular way. Dr. Williams book explains how this happens and how to avoid it.
• Software Project Management, Walker Royce, Addison Wesley, 1998. This book is getting a bit long in the tooth, but still has lots of good advice for enterprise class software development projects. This Royce is the son of Winston Royce of TRW, who's paper on Water Fall is the mots misinterpreted piece of writing in all of software development. I worked in the same build as Royce and Boehm (O6, TRW, One Space Park, Redondo Beach, CA) in the hey days of software development methodologies. 
• Managing Agile Projects, Edited by Kevin Aguanno, Multi-Media Publications, 2004. This is a good survey of how to manage "agile" projects. It is not an agile "project management" book. There is a dramatic difference between the two. Without knowing the difference you fall victim to the belief that agile software development is the same as project management.
• Catastrophic Disentanglement: Getting Software Projects Back On Track, E. M. Bennatan, Addison Wesley, 2006. This is one of the paradigm changing books. Bennatan provides a step-by-step process for rescuing software projects from the brink. Again a software project management book, not a book about software development.
• Agile Project Management, Jim Highsmith, Addison Wesley, 2004. I run hot and cold on Highsmith. I'm back, now that the hype around "agile project management" has died down. 
• Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation: Aaron Shenhar and Dov Dvir, Harvard Business School Press, 2007. This is one of the best books for corporate IT project management. I share writing duties with Dr. Shenhar in the newsletter PM Weekly Insights.
• IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Peter Weill and Jeanne Ross, Harvard Business School Press, 2004. The concept of "decision rights" is completely lost on many in the project management world. Who gets to decide is a governance question. When "all" get to decide and anyone gets to decide, the results is usually chaos at the enterprise IT level.

There are books you need that don't have Project Management in the title. These books are about the processes underlying the management of projects.

• Effective Risk Management: Some Keys to Success, 2nd Edition, Edmund Conrow, AIAA Press, 2003. Ed worked on the proposal for the Crew Exploration Vehicle (now called Orion). Ed and this book changed completely my view of programmatic and technical risk management.
• Effective Opportunity Management for Projects: Exploiting Positive Risk, David Hilson, Taylor Francis, 2004. While the notion of "positive risk" is counter intuitive and cautioned against by Ed Conrow, this book is a good survey of the concept of exploiting opportunities in projects. This is applicable during the early stages of development where change has less cost.
• Performance Based Earned Value^®, Paul Solomon and Ralph Young, John Wiley & Sons, 2007. If you want to learn how to do Earned Value right, this is the book. The "iron triangle" for modern projects is Cost, Schedule, and Technical Performance. Paul's book shows you why and how to put this concept to work. Paul is retired from Northrup Grumman where he lead the EV activities for the B-2.
• The Art of Systems Architecting, 2nd Edition, Mark Maier and Eberhardt Rechtin, CRC Press. Rechtin, is the retired president Emeritus of Aerospace Corporation, an arctitect-engineering firm specializing in space systems for the US Government. Aerospace Corporate "invented" GPS.
• The Requirements Engieering Handbook, Ralph Young, Artech House, 2004. You can't have project management without requirements management.

Yes I have the Collins book as well. It's getting less interest these days as the data from book is not holding up in practice. But sill good core ideas.

One final book The Story of Managing Project: An Interdisciplinary Approach, Elias Carayannis, Young Hoon Kwak, and Frank Anbari, Praeger, 2005. This is a survey of a broad range of project management practices in a variety of industries. My chapter "Agile Project Management Methods for IT Projects," starts on page 324.

Quote of the Day

A graceful taunt is worth a thousand insults
Louis Nizer, 20^th century trial lawyer

Project Management Books

Andrew Filev asked on his Blog awhile back, "what Project Management books should you read?" This is a good question for all project managers. But I have difficulty with the books he listed. Which may be my same difficulty with grasping the notion of PM 2.0 paradigm. 

His first "book" PMBOK^® is not a "book" about project management in the sense of the books listed below. The PMBOK^® speaks its name. It is a Guide to the Project Management Body of Knowledge. The Knowledge Areas (Integration, Scope, Time, Cost, Quality, HR, Communications, Risk, and Procurement) and Process Groups (Initiating, Planning, Executing, Monitoring and Controlling, and Closing) in PMBOK^® provide a framework for managing projects. Which by the way, if you're not doing these knowledge areas and process groups in some way, you're not doing project management. You might be doing something else, developing code, collecting "to do lists" in your email, chatting with colleagues on IM and Twitter. 

So first of all, please do not use PMBOK^® as a starting place for learning about project management. PMBOK^® is a framework assessment book. 

Here's what's on my self that I use for our practice of Program and Project Management and Program Planning and Controls.

• The Management of Projects, Peter W. G. Morris, Thomas Telford, London, 1997. You can get this book from Amazon UK or sometimes from Amazon US
• AntiPatterns in Project Management, William Brown, Skip McCormick, and Scott Thomas, John Wiley and Sons, 2000. They have other AntiPattern books as well. Although Patterns and AntiPatterns have good out of favor in the ADD world of WEB 2.0, knowing these AntiPatterns will allow you to resist the siren song of IM, Twitter, and email as a replacement for good project management processes defined in PMBOK^®.
• Modelling Complex Projects, Terry Williams, John Wiley & Sons, 2002. All nontrivial projects are complex in some way. All attempts to simplify complex projects usually fail in some spectacular way. Dr. Williams book explains how this happens and how to avoid it.
• Software Project Management, Walker Royce, Addison Wesley, 1998. This book is getting a bit long in the tooth, but still has lots of good advice for enterprise class software development projects. This Royce is the son of Winston Royce of TRW, who's paper on Water Fall is the mots misinterpreted piece of writing in all of software development. I worked in the same build as Royce and Boehm (O6, TRW, One Space Park, Redondo Beach, CA) in the hey days of software development methodologies. 
• Managing Agile Projects, Edited by Kevin Aguanno, Multi-Media Publications, 2004. This is a good survey of how to manage "agile" projects. It is not an agile "project management" book. There is a dramatic difference between the two. Without knowing the difference you fall victim to the belief that agile software development is the same as project management.
• Catastrophic Disentanglement: Getting Software Projects Back On Track, E. M. Bennatan, Addison Wesley, 2006. This is one of the paradigm changing books. Bennatan provides a step-by-step process for rescuing software projects from the brink. Again a software project management book, not a book about software development.
• Agile Project Management, Jim Highsmith, Addison Wesley, 2004. I run hot and cold on Highsmith. I'm back, now that the hype around "agile project management" has died down. 
• Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation: Aaron Shenhar and Dov Dvir, Harvard Business School Press, 2007. This is one of the best books for corporate IT project management. I share writing duties with Dr. Shenhar in the newsletter PM Weekly Insights.
• IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Peter Weill and Jeanne Ross, Harvard Business School Press, 2004. The concept of "decision rights" is completely lost on many in the project management world. Who gets to decide is a governance question. When "all" get to decide and anyone gets to decide, the results is usually chaos at the enterprise IT level.

There are books you need that don't have Project Management in the title. These books are about the processes underlying the management of projects.

• Effective Risk Management: Some Keys to Success, 2nd Edition, Edmund Conrow, AIAA Press, 2003. Ed worked on the proposal for the Crew Exploration Vehicle (now called Orion). Ed and this book changed completely my view of programmatic and technical risk management.
• Effective Opportunity Management for Projects: Exploiting Positive Risk, David Hilson, Taylor Francis, 2004. While the notion of "positive risk" is counter intuitive and cautioned against by Ed Conrow, this book is a good survey of the concept of exploiting opportunities in projects. This is applicable during the early stages of development where change has less cost.
• Performance Based Earned Value^®, Paul Solomon and Ralph Young, John Wiley & Sons, 2007. If you want to learn how to do Earned Value right, this is the book. The "iron triangle" for modern projects is Cost, Schedule, and Technical Performance. Paul's book shows you why and how to put this concept to work. Paul is retired from Northrup Grumman where he lead the EV activities for the B-2.
• The Art of Systems Architecting, 2nd Edition, Mark Maier and Eberhardt Rechtin, CRC Press. Rechtin, is the retired president Emeritus of Aerospace Corporation, an arctitect-engineering firm specializing in space systems for the US Government. Aerospace Corporate "invented" GPS.
• The Requirements Engieering Handbook, Ralph Young, Artech House, 2004. You can't have project management without requirements management.

Yes I have the Collins book as well. It's getting less interest these days as the data from book is not holding up in practice. But sill good core ideas.

One final book The Story of Managing Project: An Interdisciplinary Approach, Elias Carayannis, Young Hoon Kwak, and Frank Anbari, Praeger, 2005. This is a survey of a broad range of project management practices in a variety of industries. My chapter "Agile Project Management Methods for IT Projects," starts on page 324.