Herding Cats tag:typepad.com,2003:weblog-121343 2009-12-07T12:04:16-07:00 Ideas, Comments, and Resources about Project Management from field experiences and materials from www.niwotridge.com TypePad 40.156035-105.173659typepad/HerdingCatshttp://feedburner.google.com Quote of the Day tag:typepad.com,2003:post-6a00d8341ca4d953ef0120a7232d78970b 2009-12-07T12:04:16-07:00 2009-12-07T12:04:16-07:00 “If a profession is to sharpen its skills, to develop new skills and applications, and to gain increasing respect and credibility, then theory and practice must be closely related” – Martin Shub Glen B. Alleman
“If a profession is to sharpen its skills, to develop new skills and applications, and to gain increasing respect and credibility, then theory and practice must be closely related” – Martin Shub
 http://herdingcats.typepad.com/my_weblog/2009/12/quote-of-the-.html What is the Unit of Measure of Your Benefit? tag:typepad.com,2003:post-6a00d8341ca4d953ef0128762141f7970c 2009-12-06T18:03:17-07:00 2009-12-06T18:33:23-07:00 Tom Gilb has a wonderful post about defining "business value." When anyone makes a statement about a beneficial outcome, my first question is "what are the units of measure?" I have some favorites: Our tool saves you time - how... Glen B. Alleman

Tom Gilb has a wonderful post about defining "business value." When anyone makes a statement about a beneficial outcome, my first question is "what are the units of measure?"

I have some favorites:

  • Our tool saves you time - how much time? Can this time actually be returned to the business in terms of bookable hours that I can see in the time keeping system?
  • Our process significantly increases the quality of your product - can I see the before and after measures of quantitative quality measures?
  • Scrum is a risk reduction method - how much risk is reduced? Is this risk reduction reflected in saved cost and time for risk mitigation or risk retirement
  • Our Enterprise 2.0 solution is "easy to use" - what are the units of measure of easy?
  • Our solution integrates into your workflows - really "my" workflows? Say my ABAP SAP workflows, how about my WfMC compliant workflows? Oh not those kind of workflows. What kind of workflows?

In other words, how will I recognize what you are telling me in the absence of your physical hand waving? How will I physical confirm what you've told me is the benefit?

The absolute best unit of measure of IT projects is a monetary currency. I put money I, I get money out. All other "units of measure" cannot be exchanged at the back.

If the speaker has no tangible evidence of the beneficial outcomes in units of measure meaningful to the buyer, firmly but kindly show him the door.

 http://herdingcats.typepad.com/my_weblog/2009/12/what-is-the-unit-of-measure-of-your-metric.html Why is it so hard? tag:typepad.com,2003:post-6a00d8341ca4d953ef0128761f7e1b970c 2009-12-06T09:41:17-07:00 2009-12-06T14:54:29-07:00 Steve Romero comments on the "Same Old Problem," regarding all the reasons projects fail into the ditch. I've modified the statements a bit, but they're still true. We don't have enough resources to get the work done In our organization,... Glen B. Alleman

Steve Romero comments on the "Same Old Problem," regarding all the reasons projects fail into the ditch.

I've modified the statements a bit, but they're still true.

  • We don't have enough resources to get the work done
  • In our organization, there is no real planning process and when there is no one follows it
  • We don't prioritize our projects or the features in them. every project is a #1 priority along with the "must have" features
  • Our priorities are constantly changing with no explanation, impact analysis
  • Everyone is by passing the approved processes and then wonders why things go wrong
  • Funding tends to be very political, unstable, and not connected to the produced value
  • We can't kill a project or a feature in a project. If we do kill a project or the features, it always seems to show up again. We never have any objective measurements to overcome the politics in decision-making. 
So why are things statements true in some domains and not others? 

The Minimum Buy In Cost for Managing a Project

In the aerospace and defense business the guide of the amount of Level of Effort work runs around 10% to 12% depending on the customer. This funding goes for administrative functions: Program Management, Contracts, Program Planning and Controls.

So where is the allocation of resources for "managing" the project? The commitment to managing the project? The skills and experience in managing projects?

The CMMI-DEV 1.2 framework asks:

  • Goals
  • Commitment
  • Ability
  • Measurement
  • Verification

When I hear of projects that have "gone in the ditch," like those from Steve's post, I ask "do those project teams actually know how to manage a software project or a collection of software projects?

Sounds like the answer is no. So Steve has it right when he says 

It is heartbreaking to know so many folks continue to deal with these circumstances. I am very much looking forward to the day when these problems are a thing-of-the-past.

This is a Self-Inflicted Wound

From a recent NASA Cost Symposium paper "The Joint Confidence Level Paradox: A Historical Denial," the simplest explanation of the failure to apply sound principles to the management of projects has two conclusions:

  1. We are not really seeking probable cost and schedule accuracy (and the management of scope and requirements that comes with that), but are primarily concerned with keeping programs viable and fundable as long as possible.
  2. The variables are too complex, unquantifiable, and incalculable.

One more piece of background for failing to invest in the necessary planning and controls comes from Dan Galorath,  "Controlling Software Costs: Development is (Only) Job One"

 http://herdingcats.typepad.com/my_weblog/2009/12/why-is-it-so-hard.html Where's the PM in PM 2.0? tag:typepad.com,2003:post-6a00d8341ca4d953ef012876114ee1970c 2009-12-04T11:11:16-07:00 2009-12-04T11:47:23-07:00 The activities of managing projects take on many forms, from very formal to casual. I work in the world of formal and semi-formal programs and projects. I'm not that comfortable with all the informal approaches. But we employee people who... Glen B. Alleman

The activities of managing projects take on many forms, from very formal to casual. I work in the world of formal and semi-formal programs and projects. I'm not that comfortable with all the informal approaches. But we employee people who are.

Even in the casual projects other in or firm work - mostly internal IT projects - there are an immutable set of activities that take place - Scrum for example. These activities are immutable because in the absence of these activities in some form, there is no management of the project. It may be a project, but its not a managed project.

So what are these immutable activities?

  • Plan the Work

Formal projects plan the work from beginning to end. This is usually a contractor obligation, since the buyer wants to know how much it's going to cost to do the work or how work can be done for the available budget.

The "out years" (or months) of the project usually have lower fidelity of the details. But an end-to-end budget is needed in some form for the buyer to plan head for costs.

Less formal projects have more flexibility for budget, schedule, and requirements management (an project technical activity). But no matter the level of formality, the project participants must somehow "know" what they are working on, the sequence of the work, and what "done" looks like in some meaningful unit of measure.

  • Breakdown the Project Work Scope into Finite Pieces

All work in the project is assigned to a responsible - actually an accountable - person. For formal projects these are work packages and control accounts, with Control Account Managers (CAM). For informal projects there is still a work assignment. This can be a collective decision of who does what, but never are two people doing the same thing, or something not being done by anyone.

  • Integrate Project Work Scope, Schedule, and Cost

This integration results in a Performance Measurement Baseline (PMB). This can be as formal as a government compliant PMB submitted to SAP and reported to the DoD. Or a collection of sticky notes on the wall describing the Scrum backlog, the work for this iteration, and the names of the people assigned to each sticky. The cost in this form is the sum of the people times the hourly cost.

In all ranges, the managers of the project - be they formaly titled of the collective team - know what work they are accountable for, over what period of time they are performing the work, and how much that work is forecast to cost.

  • Capture Actual Costs

Collect the actual costs for the work performed over the period of performance. This can be as simple as level of effort for the people working the project - we've got 5 developers for our 1 month Scrum iteration. Or as complex is dozens of subcontractors, materiel procurements, and all the technical, operational, and managerial disciplines charging are various complex rates.

In all cases you must know how much your spending. OK, maybe not you - although that would be unheard of in most domains - but someone has to know, otherwise how are you going to paid.

  • Objectively Assess Accomplishments

Some how assess physical percent complete. Working software at the end of the iteration is a wonderful concept in agile. Tangible deliverables with part numbers is good. No matter what method you use, physical evidence of progress to plan is mandatory. Otherwise you have a "level of effort" project.

In the formal domain, Earned Value is the standard way. In agile working software checked in is nearly equivalent to Earned Value, minus the EV formulas. For any credible project management method assessment of physical progress is mandatory.

Not measuring = Not managing.

  • Analyze Significant Variances

If you don't know what "done" looks like, you can't tell if you're ever going to get there. No matter what project management method you're using, you must have some way to determine if you're ever going to reach the end. Measures progress to plan and determining the variance is the only way to do this.

  • Use This Information to Make Management Decisions

Decision making is what Project Management is all about. Information is needed for decision making to be effective. This information comes from the performance assessment of the project. Did you deliver more or less what the plan says you agreed to deliver? Did you do it for more or less what you planned to work cost? Did you show up more or less on the day you said you would?

These activities are the immutable elements of Project Management. There are lots of other activities around managing projects. If you have a proposed project management that does not provide outcomes in these categories, it's a none starter.

These other activities include people management - the soft side of PM, communicating with the staff, stakeholders, and other about what you're doing. Performing the Technical activities of the project - requirements, development, test, risk management, etc. But the items in the bullets are the elements of Project Management.

But I have yet see ANY of these activities mentioned by the self appointed thought leader(s) of PM 2.0.

As an aside

The term "thought leader" was coined by the first editor of Booz Allen Hamilton's Strategy+Business, 1994. A thought leader is a recognized leader in one’s field.

What differentiates a thought leader from any other knowledgeable person is the recognition from the outside world that the person deeply understands the business processes or technology, the needs of the customers of this knowledge or technology, and the broader marketplace in which the business and the technology operates.

Thought leaders are recognized externally not self proclaimed.It take a lot of hubris to call one's self a thought leader. But hey who reads history these days anyway.

 http://herdingcats.typepad.com/my_weblog/2009/12/there-is-no-pm-in-pm-20.html The Dinosaurs Didn't See It Come tag:typepad.com,2003:post-6a00d8341ca4d953ef0120a709c370970b 2009-12-03T18:19:26-07:00 2009-12-03T18:38:26-07:00 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... Glen B. Alleman

Dinosaur 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?

 http://herdingcats.typepad.com/my_weblog/2009/12/the-dinosaurs-didnt-see-it-come.html Why the Performance Measurement Baseline is the basis of project success tag:typepad.com,2003:post-6a00d8341ca4d953ef0120a6fa8802970b 2009-12-01T19:12:34-07:00 2009-12-02T22:32:12-07:00 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... Glen B. Alleman

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.

 http://herdingcats.typepad.com/my_weblog/2009/12/why-the-performance-measurement-baseline-is-the-basis-of-project-success.html Quote of the Day tag:typepad.com,2003:post-6a00d8341ca4d953ef0120a6de7705970b 2009-12-01T13:56:00-07:00 2009-12-01T13:56:00-07:00 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... Glen B. Alleman

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

 http://herdingcats.typepad.com/my_weblog/2009/12/quote-of-the-day.html Quote of the Day tag:typepad.com,2003:post-6a00d8341ca4d953ef0120a6f396a3970b 2009-11-30T21:27:11-07:00 2009-11-30T21:35:36-07:00 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... Glen B. Alleman

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.

 http://herdingcats.typepad.com/my_weblog/2009/11/quote-of-the-day-12.html The Whole Brain Look at Project Management tag:typepad.com,2003:post-6a00d8341ca4d953ef012875ee25b2970c 2009-11-30T18:16:00-07:00 2009-11-30T18:16:00-07:00 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... Glen B. Alleman

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?

 http://herdingcats.typepad.com/my_weblog/2009/11/the-whole-brain-look-at-project-management.html How Many SW Projects Have No Concern About Budget or Schedule? tag:typepad.com,2003:post-6a00d8341ca4d953ef0120a6ef14e7970b 2009-11-30T08:04:55-07:00 2009-11-30T11:26:36-07:00 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... Glen B. Alleman

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)

 http://herdingcats.typepad.com/my_weblog/2009/11/how-many-sw-projects-have-no-concern-about-budget-or-schedule.html Quote of the Day tag:typepad.com,2003:post-6a00d8341ca4d953ef012875e07ab8970c 2009-11-30T01:43:00-07:00 2009-11-30T01:43:00-07:00 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... Glen B. Alleman

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

 http://herdingcats.typepad.com/my_weblog/2009/11/quote-of-the-day-11.html Can this realy be true? tag:typepad.com,2003:post-6a00d8341ca4d953ef012875ecc5e4970c 2009-11-29T16:18:08-07:00 2009-11-29T20:55:45-07:00 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... Glen B. Alleman

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. 

 http://herdingcats.typepad.com/my_weblog/2009/11/can-this-be-true.html Quote of the Day tag:typepad.com,2003:post-6a00d8341ca4d953ef012875c7f74d970c 2009-11-28T07:39:00-07:00 2009-11-28T07:39:00-07:00 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,... Glen B. Alleman
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
 http://herdingcats.typepad.com/my_weblog/2009/11/quote-of-the-day-10.html Can PM 2.0 Cure the Common Problems with Troubled Projects? tag:typepad.com,2003:post-6a00d8341ca4d953ef0120a6e482fb970b 2009-11-27T23:46:01-07:00 2009-11-27T23:46:50-07:00 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... Glen B. Alleman

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?

 http://herdingcats.typepad.com/my_weblog/2009/11/can-pm-20-cure-the-common-problems-with-troubled-projects.html Managing By Exception tag:typepad.com,2003:post-6a00d8341ca4d953ef012875c2a143970c 2009-11-27T11:36:00-07:00 2009-11-27T11:36:00-07:00 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... Glen B. Alleman

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.

 http://herdingcats.typepad.com/my_weblog/2009/11/managing-by-exception.html petitio principii tag:typepad.com,2003:post-6a00d8341ca4d953ef012875c27de7970c 2009-11-26T10:47:00-07:00 2009-11-26T14:00:21-07:00 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... Glen B. Alleman

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.

 http://herdingcats.typepad.com/my_weblog/2009/11/petitio-principii.html PM 2.0 version 2 tag:typepad.com,2003:post-6a00d8341ca4d953ef012875dd1804970c 2009-11-25T20:20:07-07:00 2009-11-25T22:03:19-07:00 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... Glen B. Alleman

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.

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:

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.

 http://herdingcats.typepad.com/my_weblog/2009/11/pm-20-version-2.html Lazy Project Management? tag:typepad.com,2003:post-6a00d8341ca4d953ef012875d93d99970c 2009-11-25T10:08:41-07:00 2009-11-25T10:10:05-07:00 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... Glen B. Alleman

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?

 http://herdingcats.typepad.com/my_weblog/2009/11/pm-hut-has-a-post-about-lazy-management-the-idea-that-the-pm-reads-the-morning-paper-chats-at-the-coffee-machine-and-genera.html Lazy Project Management? tag:typepad.com,2003:post-6a00d8341ca4d953ef012875d93818970c 2009-11-25T10:03:23-07:00 2009-11-25T10:03:23-07:00 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... Glen B. Alleman

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?

 http://herdingcats.typepad.com/my_weblog/2009/11/lazy-project-management.html Quote of the Day tag:typepad.com,2003:post-6a00d8341ca4d953ef012875c26f21970c 2009-11-25T10:00:00-07:00 2009-11-25T10:00:00-07:00 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 Glen B. Alleman
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
 http://herdingcats.typepad.com/my_weblog/2009/11/quote-of-the-day-8.html