Leaders and Managers

At one time--quite a few years ago now--as a contractor in the construction business with several teams of hard-working people, lessons about improving the way people come together to accomplish goals was a daily part of life. It still is today but one such incident from that earlier time stands out with great clarity, a memory and line of thinking that has only grown more important with the passage of time.


Two new employees (first day on the job) are excavating around the perimeter of the job site one afternoon. Due to terrain and existing obstructions, they are manually excavating a trench with shovels and picks.  Eventually, the trench becomes a footing for a small stone retaining wall alongside exterior concrete walkways. Even standing on the other side of the job site, the grumbling and muttering between the two excavators along with their frequent questioning stares around the area at the activity of others is a sure indication of some issue. 


The Supervisor (also a new employee) and I are discussing plans and logistics in a "quiet" spot. The drama implicit in the actions of the two newbies grumbling their way through the sticky, black clay is demanding more and more of my attention. After we decide the planning and logistical questions, I ask the Super how the two new employees are doing. He shakes his head, lowers his eyes, staring soulfully at the tip of his boots, saying, "I just don't know. They seemed sharp enough--and, maybe they are. They claimed they were ready to work but... well, they might not pan out."


"You want me to have a talk with them," I quietly suggest?


"Sure," he says looking up, "Maybe you can talk some sense into them."


So I make the rounds of the job site, wandering a bit and casually talking with crew and subs while incrementally approaching the two shovel wielding newbies. When I reach them, I introduce myself, shake hands, and ask them how their first day is going.


Their initial response is a rather dismal, "OK, I guess," without any eye contact. To continue the conversation and draw them out I ask, "What are you building here?" pointing to the excavation.


The answer is stunning. They both simultaneously exclaim, "That's the problem: We don't know!"


Yes, that is certainly a problem: Sound familiar?


It happens a lot in every area of human endeavor. Instead of bringing new people on board through the sharing of vision, goals, and desired outcomes, a different approach is taken. One that involves unilateral command, disciplinary action, and micro-management. It goes something like, "Dig a hole from point A to point B at a depth of C with a width of D. Get it done today or don't come back tomorrow." 


That is a recipe, as a manager, for long fruitless hours, stress, heart attack, poor outcomes, and failed projects. A machine might be "managed" in that way but people must be led. 


So, I gave 30 minutes of time to the new employees discussing our company, our organization and the project we were working. Not "laying down the law," instead having a frank and open discussion. When they understood the basics and questions were answered, we reviewed the details of this specific excavation. We pulled out plans and discussed what the client wanted, where, and how we expected to make it happen. I showed them where what they were doing today fit into the plan, why it was so important, and how we were depending on them to achieve the desired outcome. 


They "got it." Done.


When they understood the goals and had a clear picture of the outcome expected, they went back to work without grumbling, without questions, and continued to do excellent work for the remainder of the project. The excavation was finished that day ahead of schedule and without any need for rework or any further conversation. 


When I explained the situation to the Super and showed him how it worked on subsequent occasions, he became a skilled mentor in bringing people on board and a highly valued member of the organization. The two excavators, last I heard, were quite successful as owners of their own businesses. 


People who are talented and capable, people who are committed, engaged, and on board with the goals will self organize to achieve those goals. 

Posted by: William W. (Woody) Williams

Subscribe

Planning Value

The value in creating plans is not found in blindly following them but in using them as tools to intelligently and proactively manage inevitable change.

Posted by: William W. (Woody) Williams

Subscribe

Inevitable

Change is both rapid and constant. Proactively embrace that fact in ways that drive improvement.

Creating plans, process, and methods that address the inevitable changes of circumstance may seem daunting.  However, to do otherwise is to expect that circumstances change to fit plans, processes, and methods which makes disaster inevitable.

Posted by: William W. (Woody) Williams

Subscribe

Why small is sometimes big

‎"Starting small" doesn't necessarily mean doing small things. Starting step one of massive, complex, daunting goal broken down and prioritized in manageable chunks is "starting small." Starting is the key.

Posted by: William W. (Woody) Williams

Subscribe

Hyperbole

Hyperbole is the downfall of requirements, proposals, and status reports.

Posted by: William W. (Woody) Williams

Subscribe

I am a project manager

I am a project manager: At its most basic, that means knowing "how" to get things done. That "how" stands, primarily, for "process." Many, but not all, my thoughts here share that focus on process.


I am deeply involved in both program and portfolio management. That means not just"how" but "what" and "why" and "when." "What" is to be accomplished could be referred to as "the ends." "How" the thing is accomplished, then, refers to "the means." "Why" is the strategic framework. "When" is about organizing the various "what's" into a logical sequence of events.


Standing outside the context of business and business technology I often speak to social, political, or cultural issues. Not here on this forum but on others. We (myself along with other project managers) have something to share; it's important. Important in the context of business, technology, and important in the larger context of getting things done in life.


Regardless of how carefully and rightfully the vision is crafted, goals defined, and success factors enumerated, if the methods, techniques, processes, and people employed are imperfect, those imperfections become realized in the outcome. In a sense, the end becomes the means.


We never achieve greatness (success) through flawed means. The most brilliant strategy is brought to naught by tactical failure. No amount of individual effort can overcome it; no amount of shiny rhetoric can gloss it over; neither advertising nor marketing can salvage it.

Posted by: William W. (Woody) Williams

Subscribe

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

Project Objectives: An Addendum

A few weeks ago a fellow PM, blogger, and tweeter to the Project Managers on Twitter group (Josh Nankivel) posted an interesting and thoughtful piece called "Project Objectives and Deliverables" on his blog (pmStudent).

First a little about Josh. The word "student" in the blog title describes the intended audience, not his qualifications.

..is the founder of pmStudent.com, a site dedicated to helping new and aspiring project managers succeed. He is a project manager and contractor for the ground system of the Landsat Data Continuity Mission, a joint project between the USGS and NASA. Josh's academic background includes a BS in Project Management and holds the PMP certification.

In this piece, Josh establishes a relationship between project objectives, deliverables, and activities: Objectives >> External Deliverables >> Internal Deliverables >> Activities. It is the response to this from readers that is most interesting.

There is, apparently, a bit of misunderstanding around the concepts of objectives, deliverables, and the WBS (Work Breakdown Structure) within the community of project management practitioners. The comments following the post are worth reading for context as is the piece by Josh that started the discussion: Here.

You may have read my response in the comments if you followed that link but if not, it is posted below. A fairly succinct, straight-up description of project objectives that holds true in Agile teams as well as other contexts. I've added an addendum as well.

---

Objectives (project objectives, in this case) are concise statements that define what the project will achieve. They are written in business terms. I like the SMART approach - Specific, Measurable, Attainable/Achievable, Realistic, and Time-bound.

If you can’t get a sense of the deliverable(s) needed to achieve the objective, it may be written at too high a level. If an objective describes the characteristic(s) of a deliverable, it may be written at too granular a level. If the statement describes features or functions, it is a requirement, not an objective.

Objectives are important for three major reasons.

1. They are in business terms. Once they are approved, they represent an agreement between the project manager and the project sponsor (and other major stakeholders) on the main purpose of the project. The specific deliverables of an IT project, for instance, may or may not make sense to the project sponsor. However, the objectives should be written in a way that they are understandable by all of the project stakeholders.

2. They help frame the project. If you know the project objectives, you can determine the deliverables needed to achieve the objectives. This in turn helps nail down the overall project scope, helps you identify risks and allows you to provide estimates on effort, duration and cost. Once the project starts, you can validate that all of the work that you are performing will ultimately help you achieve one or more project objectives.

3. They help you declare success. At the end of the project, you should be able to talk to your sponsor to determine whether everything expected in the project objectives has, in fact, been achieved. If all of the objectives were not fully met, you may still be able to declare partial success.

The project objectives should be defined and agreed upon before the project starts. The deliverables of the project are created based on the objectives - not the other way around. That is, you don’t agree on the deliverables first and then establish objectives to match. You must understand the objectives of a project and then determine the deliverables that are needed to achieve them. You would then structure the entire project to meet the project objectives.

---

Addendum

It is worthwhile noting that objectives, during a project lifecycle, can and do change -- usually through an evolutionary process based on refinement or new knowledge. In addition, internal business or external market conditions may change as well, forcing a re-evaluation of project objectives. A change in objective(s), however, is not as common as other types of change in a project.

If objectives do change, it is a different level of change than, for example, a requirement or user story change modifying a deliverable. Deleting, adding, or significantly modifying a project objective usually means a wholesale, major change in direction for a project. This, among others, is one reason getting objectives right from the start is so critical.

For example, here is a hypothetical project objective or goal: "The percentage of web site visitors converted to paying customers will increase 30% by end of year.

If the percentage within the objective changes significantly, the time limit increases or decreases, or the objective is eliminated entirely during the course of the project , the impact to user stories and deliverables could be quite dramatic.

If objectives are clear and understood, project priorities can be set clearly and intelligently as well. The more a group (team) really understands what their purpose is, the more clearly they can see the way forward. Objectives are critical to self-direction.

Posted by: William W. (Woody) Williams

Subscribe

PM Humor: On the Course...

A clergyman, a doctor and a project manager were playing golf together one day and were waiting for a particularly slow group ahead. The project manager exclaimed, "What's with these people? We've been waiting over half and hour! It's a complete disgrace."

The doctor agreed, "They're hopeless, I've never seen such a rabble on a golf course."

The clergyman spotted the approaching greenkeeper and asked him what was going on, "What's happening with that group ahead of us? They're surely too slow and useless to be playing, aren't they?"

The greenkeeper replied, "Oh, yes, that's a group of blind fire-fighters. They lost their sight saving our clubhouse from a fire last year, so we always let them play for free anytime."

The three golfers fell silent for a moment. The clergyman said, "Oh dear, that's so sad. I shall say some special prayers for them tonight." The doctor added, rather meekly, "That's a good thought. I'll get in touch with an ophthalmic surgeon friend of mine to see if there's anything that can be done for them."

After pondering the situation for a few seconds, the project manager turned to the greenkeeper and asked, "Why can't they play at night?"

Source: http://www.businessballs.com

Posted by: William W. (Woody) Williams

Subscribe

And Then What?

It is often said that change is inevitable. A friend in the door64 and LinkedIn communities recently posed this question:

"As you know, the real problem is once there are structural changes in an economy or economic system, the "return to normal" never really gets to "normal." Job displacement, under employment, unemployment, regardless of how you say it means that skills are lost to an economy or a region. Then what?"

"Then what" is a really good question in any situation dealing with change -- personal, project, or huge macro shifts in social and governmental areas. Truth of the matter is we cannot forecast all potential outcomes from change -- negative or positive.

This (below) is the response given.

---

Then What: Change

At risk of seeming both specious and simplistic, the answer to "then what" is "change." And, change comes with both positive and negative effects; unintended consequences as well as known and unknown outcomes.

Disclaimer: The term "change" is used here without political implications. It is simply "change" in the dictionary sense.

The one central fact around change at the macro level is that we humans lack the ability to fully understand or forecast its result. And, that's not from lack of effort or rhetoric. We see change in an historical context with 20/20 hindsight but our vision is blurred as we turn our attention to the future.

Lessons Learned

One lesson from history is that becoming locked in a paradigm while faced with a sea change leads to disaster.

• The naval defeat of Carthage
• The British defeat in the American Revolution
• The antebellum South
• A lot more

The lesson is that when groups of people -- nations and states as well -- believe with the fierce faith of fanatics and depend entirely for their survival only on solutions or paradigms that worked well in the past, doom is certain; now or later. Change is inevitable and it tramples us unless we face it, learn from it, and move ahead with fresh solutions.

Electric lights put people out of work and changed lives. The steam engine, cotton gin, assembly line, radio and TV, movies, and the PC did as well. Refrigerators, central air and heat, and countless other things - at their inception - put people out of work and disrupted stable lives build on a belief that what worked in the past is "good," will always work, and will always remain "good."

And, that's just not true.

Good and Evil

Change is inevitable but neither all good nor all evil. Change comes fully loaded with both positives and negatives.

"Job displacement, under employment, unemployment...skills lost to an economy or a region" are short-term negative affects of economic change. To the extent that people hold on to the the past and believe the only answer is more of that past, the short-term negative becomes a long-term death sentence.

To the extent that we as a people, we as managers, or we as a government continue to support people affected by change in a manner that continues their reliance on the broken past instead of offering solutions for the new future, we are enablers of continued failure.

It is probably not about "getting those jobs back," or "keeping those skills" as much as it is about creating new jobs, innovation, entrepreneurship, training / retraining in new skills, starting fresh... Telling people the truth about their future including the fact that some of that future is unknown. It takes credibility and transparency in leadership. This is an axiom -- almost a rule -- for anyone managing change.

The invention and use of automobiles shut down equine related businesses. What would have happened if government stepped in as a manager to "control" that situation?

• Subsidies to blacksmiths, carriage makers, and horse trainers
• Outlawing auto manufacturing
• Putting tariffs on the import of automobiles
• High taxes on the sale and use of automobiles
  
• Laws against driving "horseless carriages" down Main Street

Truth and Transition

None of those things stopped the automotive revolution any more than similar measures will stop or "control" the current change cycle -- or any change at any level. If it is inevitable, it can't be stopped but we can sure make the transition easier.

We're better off in the long run telling people the truth about the change especially when jobs and financial futures are at stake. As managers or enablers, we help people accept the fact that change is necessary, celebrate and make possible "fresh starts," give those affected by change the tools and information to handle it well, and move it forward quickly.

Wrap It Up

Another saying is that "People don't resist change, they resist being changed." That means it's personal. The failure of managers at all levels to recognize, and manage to that most personal and instinctual level leads to the most negative of outcomes. It's not that people "take it personally" creating a problem... It is personal and that's part of the solution.

---

Posted by: William W. (Woody) Williams

Subscribe

Project Management Tools

Tools are not what make project managers effective or ineffective but they can make us more productive. Tools like MS Project, Project Server, Sharepoint, Primavera, and others are widely used in organizations. Most project managers are familiar with several.

As a resource for project managers and those interested in project management, we are compiling a list of tools suggested by other project managers. They are presented for research and informational purposes, not as a "recommendation" from enweave although each of the tools listed has been suggested to us by a project manager (not the software provider or dealer). Your mileage may vary.

In addition, there are links to some general project management tool resources (other listings) that might be helpful looking for a specific tool or getting a feel for the field.

If you have a favorite, a suggestion, or a notes on a specific application, please leave a comment here or connect with us via Twitter or LinkedIn.

Tools Suggested by Others

http://www.attask.co.uk/
https://www.manymoon.com/misc/help
http://www.project.net/
http://www.ppmstudio.com/index.aspx
http://projectoffice.net/
http://www.mpmm.com/
http://www.seavus.com/
http://www.openworkbench.org/
http://projects.zoho.com/
http://www.huddle.net/
http://www.projectorpsa.com/

General Listings of Tools

Agile Specific - primarily open source
http://www.agile-tools.net/

Scrum Specific - primarily open source
http://www.scrum-breakfast.com/2008/07/directory-of-scrum-management-tools.html

Extensive listing on Wikipedia covering most makes and models:
http://en.wikipedia.org/wiki/List_of_project_management_software

Posted by: William W. (Woody) Williams

Subscribe

Rapid Project Inception

Overview of Agile and specific opportunities for employing Agile methodologies. Good Read.

Rapid Project Inception

View more presentations from udairaj.