How do you run a project?

---

A couple having coffee and conversation one morning...

"How do you run a project," she says.

He says, "What kind of project?"

Short pause; she says, "Well. Um. Any project... There must be some standards about running projects?"

A little frustrated, he replies, "What are you building? A house, a road, a bridge, a website?

Equally frustrated and a getting a bit tense, she says, "I'm not building anything. I just want to understand how to run a better project."

---

This conversation mirrors many conversations -- where two or more people look at the same thing but see something different. In this case one person sees the way a project is run as primarily dependent on the output (product) of the project. In other words a lot of variation from project to project related to the technical details. The other person sees the way projects are run as a type of management activity -- a lot of similarity from project to project unrelated to technical details.

Who's right?

---

Does project management look like this (Drawing A)?

Or like this (Drawing B)?

---

Obviously there are more project types than those shown but... you get the idea.

The answer to the question "Which one more closely mirrors the practice of project management?" is, in one sense, both and, in another, neither. Yes, dichotomies like this are common. This one, however, is relatively simple to clear up.

Drawing B is primarily depicting the importance of domain knowledge.

domain knowledge That knowledge which is specific to an application, as distinguished from general strategic or control knowledge that is independent of the details of any particular application. For example, data about the flight routes covered by a particular airline is domain knowledge, unlike search algorithms that might be used to locate the cheapest entry. ~ JOHN DAINTITH. "domain knowledge." A Dictionary of Computing. 2004. Encyclopedia.com. 6 Jun. 2009 <http://www.encyclopedia.com>.

Drawing B implies that there is little or no overlap - no common ground - between a construction project and a marketing project. It could be adjusted to show some overlap - an area of super-pink where all the circles converge (below). A lot of people see project management as one or the other of those domain specific models.

Drawing A depicts a different level of management -- an uber-management that applies to all projects. Drawing A also includes the concept of domain knowledge as different types of projects, based on domain knowledge, are included as sub-sets. However, Drawing A infers there is a broader, more general type of knowledge that applies to all projects regardless of domain - the blue area outside the domain of any specific project.

So, is managing a project to construct a bridge along an interstate highway the same as managing a project to bring a new type of aircraft into production or managing a project to produce a new pharmaceutical?

If the goal is a successful project, the answer is both "Yes," and "No."

Another dichotomy!

OK: Actually it's the same dichotomy put in slightly different terms -- and adding "successful."

Why add "successful?"

Because almost anyone, with or without knowledge or experience, can manage a project unsuccessfully.

---

Project Management - The Uber-Management

The Project Management Institute (PMI) defines project management this way, “The application of knowledge, skills, tools, and techniques to project activities to meet project requirements." Details are spelled out in the Project Management Book of Knowledge (PMBOK), currently going into its fourth edition. While there are other project management methodologies, this one is generally accepted and used as the standard here.

Some take issue with the PMI definition as being overly "scientific" but it still remains as a good, working definition describing the boundaries of project management. While there is no specific domain knowledge called out in the definition, it could be useful to assume that "knowledge, skills, tools, and techniques" include expertise specific to the domain of a particular project. However, there is a distinction and a difference between what is "project management" and what might be called "expertise management" or "domain management."

Domain Management - Expertise

There are a number of specific knowledge areas, skills, tools, and techniques required to manage a pharmaceutical lab, for example. Even though someone is highly skilled in management -- say in retail stores -- no one would assume they could successfully manage the pharmaceutical lab without experience. They might do considerably better than someone with no management experience at all but another person with less management experience who does have a pharmaceutical background will probably do better.

This seems rather intuitive -- because it is intuitive. However, many people fail to recognize that project management is distinct from management in general and a separate field of specialization. In other words, project management is not included in their intuitive paradigm or comparison model. It should be.

Integration

While the laboratory manager cited above may be awesome with the operations side of the business, that does not mean they are capable of successfully managing projects. Project management has a set of knowledge areas, skills, tools, and techniques separate and distinct from laboratory management, retail management, or any other management domain.

There are overlaps but these overlaps are essentially on the same order of magnitude mentioned in the example above -- that a retail manager might do a better job as laboratory manager than someone with no management experience at all but it will be very difficult to succeed until the requisite experience is gained. This is the case with project management as well.

A certified (professional) project manager from any domain will do a better job at managing a project in a different domain than someone with no project management experience at all -- but, will still struggle to be successful until the specialized domain experience is gained.

A certified (professional) project manager with less overall project management experience who does have specific domain management experience will probably do a better job than a more experienced project manager lacking the domain management background.

An experienced domain manager with no project management credentials or experience will, most likely, do poorest of all.

In this case, a "certified (professional) project manager" refers specifically to the certification credential from PMI - the Project Management Professional (PMP) designation. Since PMI is the standard in this article, a word about the PMP credential is appropriate.

Attaining the PMP designation requires not only vast knowledge as proven by testing but also years of proven experience. "Book knowledge" as well as verifiable hands-on experience are required. It's not easy and many people fail to achieve it. Bottom line: Recent studies indicate that in projects completed successfully, the vast majority are led by a certified project manager.

Wrap It Up

Back to the intuitive side of this discussion: No one feels comfortable about having a project manager in charge of developing the next great cancer treatment who has only managed highway construction projects in the past and who has no pharmaceutical research background. Where it becomes less intuitive is when the domain management experience is driven down to an absurd level of granularity.

For example, "Project manager needed with experience managing left-handed Java developers in an underwater environment and a background in bakery products containing cinnamon and sesame seeds fired in wood-fueled ovens outdoors at night in the mountains."

That's taking it a bit too far. There's a difference between domain knowledge boundaries and hair splitting. The example above is admittedly absurd but, unfortunately not too far from the truth. Many organization put more emphasis on subterranean levels of domain expertise than on project management expertise -- to their detriment.

There are two important, high-level types of domain knowledge. One involves the line of business and the other relates to the development work planned (technical domain knowledge). It's probably most important for project managers to have experience in the line of business (managing projects for bakeries, for example) so as to understand the business domain, its sub-domains, and business needs.

Expertise in the specific programming language (Java) or other techniques used by the developers is of secondary or tertiary importance to the project manager. That level of technical domain knowledge is of primary importance in choosing a team lead, technical lead, or lead developer. That said, a certified project manager with line-of-business domain knowledge (bakeries) who also has technical domain knowledge (Java development) is probably most likely to be successful.

To answer the ladies question at the beginning of this article, "Yes, there is a standard body of knowledge for project managers." It's more a toolbox of best practices that requires experience to utilize effectively. In other words, it's not one-size-fits-all and it's not paint-by-numbers. Successful project managers are familiar with and experienced in using all the tools in the box and, most importantly, have the wisdom and experience to select the correct tool or tools for the job at hand.

In response to the gentleman's questions at the beginning of this article, "Yes, it does matter what is being built but it takes more than domain knowledge to successfully manage projects." As one wag put it, "If all you have is a hammer, everything starts to look like a nail." Domain knowledge is extremely useful but successful projects are about more than domain knowledge -- technical or line-of-business.

Finally, here's a look at Drawing C -- something more like what project managers do in the real world.

Drawing C implies there is domain management knowledge outside the realm of any specific project. It also implies the same about project management knowledge. For any specific project, there is a sub-set of both project management knowledge and domain management knowledge involved.

For successful projects, balance is needed between project management and domain management... With the caveat that significant project management expertise is always required for success. The level of project management expertise may be tempered by the need for domain management experience but project management experience remains the prime indicator of potential success.

Subscribe

Defining Project Success

For decades, project managers preached the mantra of the "Iron Triangle" to project teams and stakeholders: Cost, Time, and Scope, also known as the "Triple Constraint."

The Iron Triangle

There has always been some variation in the terms used for the "legs" of the Triple Constraint and many practitioners recognize more than three constraints including PMI who added "legs" in the most recent revision (fourth edition) of PMBOK. Nevertheless, the Iron Triangle still stands today as a guiding principle of practice with the majority of project managers.

Define "success"

Many organizations defined project success based on some variation of the Triple Constraint for decades as well, some placing more emphasis or value on one leg or some combination of legs. In actual practice, there is no "standard" measure of project success across all organizations so generalizations about as well as comparisons of project success metrics are difficult. However, most are based in whole or in part on some flavor of the Triple Constraint.

Software projects, in particular, have a very poor reputation for success (Standish and others). This is largely the result of "waterfall thinking" and poor survey design but the mud slung at software projects still sticks to the wall. A great deal of that mud should be washed away and the concept of how "success" is defined in technology projects is in need of a make-over.

Why?

Because surveys and other data gathered to determine success or failure of projects are, most often, based on comparing final (closed) project metrics with original (baseline) estimates of cost, schedule, and scope. In the case of a building, road, or bridge project, this approach makes a certain amount of sense -- the thing (product) is designed up front and delivered according to design. In the case of most software projects, the thing (product) is an amorphous concept at best that can and does change radically in design as development proceeds.

In the case of a bridge construction project, there may be schedule delays or cost over-runs due to weather, late delivery of materials, lack of resources on site, and the like but there is never any doubt about what the finished product is or what it should do. It's "this wide" and "this tall" and is "this type" with "these materials" and carries "X" lanes of traffic. That is known not only before the start of construction but before anyone bids the job. Both the problem and the solution, defined in great detail, are known.

That is almost never the case with software development projects.

Problem?

You bet!

Many software projects declared a "success" based on meeting the original scope, time, and cost criteria are actually failures because the product delivered didn't meet the business needs. This may seem oxymoronic at first blush but is most assuredly the case. It means the criteria for measuring success is probably wrong, incomplete, or inconsistent with reality... the wrong things are measured; the wrong criteria are managed.

Define "failure"

If a project delivers 25% behind schedule and 30% over budget but the business need is met and the numbers still "crunch" in terms of ROI, this project is still declared a failure according to most measurement methods. The project manager didn't meet the scheduled delivery dates and there was a serious (30%) cost over run. The business could make or save millions of dollars as a result of the effort but it goes down in the record book as an failure. The stakeholders are disappointed, the project manager is squirming on the hook, and the delivery team is demoralized. Another apparent oxymoron and an issue with the criteria used.

This is an example of 19th and early 20th century "waterfall thinking" at its worst. The project team is expected to know the unknowable from the start before anything is known, then make an estimate and plan based on both the unknown and the unknowable, and finally live or die by the planned (baseline) scope, schedule, and cost. It's no wonder software development and technology people have stress issues.

Where's the product?

In the Triple Constraint, the only leg specifically applicable to product is Scope with the caveat that Quality also plays in the product space. However, quality is most often measured by how well the project adheres to whatever "process" is mandated and the number of defects detected -- Quality Assurance and Quality Control.

In the case of defects in software projects, they are determined by comparing results of test cases (which do not cover 100% of the possibilities) with the product design specifications. If the design specifications do not meet the business needs, this is not a "defect."

In the case of "process adherence," the product is never measured or considered; customer satisfaction is not a criteria.

The business results from the product produced are reviewed (if at all) in a post-implementation review, usually some months after the project ends. By the time this review process occurs, the project is usually already on the books as a success or failure.

Another problem?

Uh huh.

Negotiation or criteria?

The Triple Constraint is more about negotiation than anything else. Negotiation is intuitive; no degrees or certifications required. Everyone "gets it" and uses it when making a significant purchase - a car, refrigerator, or home, for example. Some people are better at negotiation than others, but everyone understands.

No one wants to pay more than it's worth, wait any longer than they have to for delivery, accept a scaled down version, or pay for added features that are not needed. That's the Triple Constraint in a nutshell -- a simple negotiation model. "You can get siding instead of brick for much less," or "We have this color on the lot right now; if you want that color it will take three weeks for delivery." It's negotiation.

Granted, the Triple Constraint works well in negotiation; at least as a starting point for negotiation. And, granted, negotiation plays a substantial role in a project managers life. However, when the concept of the problem/solution/product is still being elaborated... still being negotiated... still fluid and may remain so until almost the end of the project, how well does the Triple Constraint baseline concept work as the criteria for determining the success of the effort?

Not very well.

It works great if what is needed is already known -- like ordering a car or a hamburger. The "problem" is known (lack of transportation, or hunger) and the "solution" is obvious (a car or hamburger). Only negotiating the price, features, and delivery schedule remains. Using the terms of the final negotiation as the criteria for success, arguably perhaps, makes a lot of sense in these cases. But, can a business "place an order" with its IT department to solve a problem not fully understand by implementing a solution that hasn't been created?

Not likely.

If almost nothing (or somewhere between nothing and something) is known about the problem/solution/product up front, those things can not be negotiated to a baseline up front. They must be continuously negotiated, continuously elaborated and defined/refined as the project proceeds. If that's the case (and it certainly is with many software development and technological innovation efforts), then what is the criteria for success and what do project managers manage to in terms of project objectives or goals?

Software and technology project managers are obviously not defining the correct criteria -- or at least not including a full set of criteria needed to manage software and technology development efforts.

How does that improve?

By asking people what they want and need... And, continuously asking them for those needs and feedback based on actual results as the project proceeds. By engaging and collaborated with everyone throughout the project to ensure their needs are met.

What does success look like?

On the Dr. Dobbs web site (yes, they still exist ;~), there is an article on defining project success; a nice one. It's brief (3 pages) so read it here if you have a few minutes.

In the article, Scott W. Ambler (of Agile and IBM Rational fame), publishes poll results based on using five criteria for project success. Here's what respondents considered important.

• Schedule: 61.3 percent of respondents said that it is more important to deliver a system when it is ready to be shipped than to deliver it on time.
• Scope: 87.3 percent said that meeting the actual needs of stakeholders is more important than building the system to specification.
• Money: 79.6 percent said that providing the best return on investment (ROI) is more important than delivering a system under budget.
• Quality: 87.3 percent said that delivering high quality is more important than delivering on time and on budget.
• Staff: 75.8 percent said that having a healthy, both mentally and physically, workplace is more important than delivering on time and on budget.

Note: Read more about the number and type of respondents in the article on page 3.

Wrap it up

Scott's acquired and compiled data is excellent information and puts the success criteria for technology development efforts in much better perspective. It is difficult to convey just how refreshing this is to a project manager who has battled the Triple Constraint success criteria for many years.

• ROI is more important than budget.
• Meeting the needs of people (stakeholders) is more important than specifications.
• Readiness is more important than schedule.
• Quality is more important than schedule or cost.
• Mentally and physically healthy people are more important than schedule or cost.

Sound familiar?

Read the Agile Manifesto recently?

There is great emphasis from survey respondents on the condition of the final product as opposed to arbitrary milestones or deadlines. Does the product actually fill the (changing, evolving) needs of the customer when delivered? Is the product really ready for delivery or is this just meeting an arbitrary deadline with an unfinished product? Is the quality of the product at a level where it can be placed in users hands or on the market with confidence or does it require further refinement?

There is great emphasis from survey respondents on the condition of people as opposed to resource allocation, task assignments, or effort/hours. "The needs of people (stakeholders)", and "Mentally and physically healthy people." Products meet and are defined by people's needs and people create extraordinary products out of joy and passion; collaboration and understanding; mutual respect and teamwork.

Obviously it seems the real success criteria and priorities for project stakeholders lie in determining/defining the state of the final product and the state/condition of all the people involved -- stakeholders, users, team members, managers; everyone.

ROI is a number managers can use. Readiness is quantifiable. "Needs" can be determined, continuously elaborated, refined and met. Quality is definable. Healthy, happy, passionate people are something managers can monitor, mentor, and support.

There is still room for negotiation around the Triple Constraint. For example, when a customer has an undefined need but a budgetary constraint, the project can be designed to deliver whatever scope is achievable within the budget. A "time-box" can also be applied limiting the development effort to the scope achievable within a set time frame. In most cases where the team (number of people on the development team) is known, a time-box has the same effect as a budget constraint.

Too often, when project managers say "we get results," they mean meeting arbitrary deadlines instead of producing products that meet people's needs. The sacrifices people make meeting meaningless milestones, jumping through hoops to stay within purposeless budgets, and achieving arbitrary deadlines add nothing of value to the product and are inherently demeaning. Those sacrifices have tremendous negative impact to their family and friends, their health and well being, the health and safety of the work place as well as the quality, readiness, and suitability of the product. Sad, worn-out, desperate, unhappy people do not make extraordinary products.

This is not to say that baselines, budgets, schedules, processes, techniques, and tools are not important. They are. But only if and when they are based on the right criteria and balanced with a focus on people and the final product.

When do managers start giving people (stakeholders, project teams, and users) what they really want and need?

How about right now: Today is good.

Posted by: William W. (Woody) Williams

Subscribe

Balancing Discipline w/Agility: Is it "Balance" we Really want?

No trade-offs; nothing is sacred; the relationship is 100%/100% - Good presentation here.

Balancing Discipline w/Agility: Is it "Balance" we Really want?

View more OpenOffice presentations from Hillel Glazer.