Simple Problems...

Simple problems can be made confusing, complex and insoluble if enough meetings are held to discuss.

Instant Destruction

Credibility and trust take a long time to develop; are destroyed in an instant.

Focus for Accountability

IT projects focused on implementing a system instead of a business goal lack accountability.

Change and Choice

The forces of change are constant. Helping make change occur in a positive manner is a choice.

Delivering Matters

When a project fails to deliver what it's supposed to deliver, little else about the thing will matter.

Complexity

Complexity is not sophistication - anything incomprehensible should cause suspicion rather than admiration.

First things first...

The ability to change yourself is a precursor to effectively changing others.

Organization change first

Using a methodology or approach unsupported by the current organizational culture will fail.

Goals and Clarity

The biggest obstacle to progress and primary time waster on projects is confusion about goals.

Priorities

Prioritize in this order: Goals, features, and then work items. A project can run on these 3 lists alone.

Looking for a silver bullet?

"Silver Bullets" are found in people, values, and communications not methodologies.

Complexity and Confusion

Complexity is not a cause of confusion. It is a result of it. ~Jeff Hawkins

Activity Sequencing

When walking single file, no one moves faster than the one ahead or slower than the one behind.

Stability

In the face of rampant technology, human systems (psychology, sociology, politics, economics) are amazingly stable.

Good Leadership is Obvious

Good leadership is an obvious trait from day one on the job. It's not a seminar or a book.

New Position

Signed a consulting deal with RenewData in Austin, TX last week as Senior Project Manager in their PMO (Program Management Office) starting Monday, October 5. We expect this to become a long-term position.

The position is similar to ones held in the past. Primary duties include process improvement initiatives, PMO governance, Portfolio, Program, and Project Management.

The interview process was intensive and exhaustive. At the end, we reached the mutual conclusion that this position is a good fit for myself and for RenewData. It is a very exciting opportunity with a growing company, in an expanding market, with excellent people on staff.

Posted by: William W. (Woody) Williams

Subscribe

Right team, wrong problem?

If your team isn't experienced solving the type of problem presented, ask: Why this team? Why this problem?

Cost is important but...

If you spend all your time validating cost data you are blind to real risks and forgotten items.

Simplicity

For most product end users, simplicity is more important than comprehensiveness or complexity.

Who's Smartest?

If the project manager is the smartest team member, resource acquisition failed.

The Success of Canceled Projects

Inspired by our Twitter comment, Steve Romero in his "The IT Governance Evangelist" blog carries the comment further. Worth the read and should inspire some thoughts on your own organization.

The Success of Canceled Projects

Shared via AddThis

Consider this in your holiday plans

Labor Day is a holiday... but not for the unemployed. Something to consider as we, in the US, celebrate a holiday dedicated to workers and working.

Every Organization and Employee Should Read This

Read this (below) internal presentation from NetFlix. Go through the whole thing - it is meant to be read, not "presented."

Think about it.

How does your organization compare?

How do you compare?

What changes can you make in yourself and your organization?

Culture

View more presentations from reed2001.

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.

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

Quotes from the Boss

---

Project sponsor commenting on results from GUI design session, "I guess with enough practice, any interface is intuitive."

---

"You get the guys started coding. I'll go find out what the client wants." ~ VP to Project Mangager

---

"Teamwork is a lot of people doing exactly what I say." ~The Boss

---

Program Manager and VP discussing potential projects.

VP: "This is a good concept and there's a huge value proposition to it. Unfortunately, we looked at doing the same thing last but decided not to fund the effort."

PM: "Really? That's interesting: Why did you kill the project?"

VP: "Well... we decided it was too hard."

PM: [pause] "This project means millions in ROI and about the same in cost savings. We're not doing it because it's hard?"

VP: [pause] "Yes."

PM: "Should we rethink that?"

VP: "No. It's too hard."

---

"640K ought to be enough for anybody." -- Bill Gates, 1981

---

Programmer: "This design isn't going to work. We were wrong in our assumptions and we can't deliver it."

Manager: "What will it take to change the project documentation and make it read like we knew this from the start?"

---

Subscribe

Twitter Expectations

Twitter Expectations: What to expect from @threew

The Tweets

I begin most days reviewing the thoughts of others as well as my own experiences in the process of energizing and motivating myself for the work to come. The habit of positive thought and creative reflection is one of long standing... What's new in the mix is Twitter.

Twitter has become an important a tool to help distill those thoughts... flush out inconsistencies and expose errors. Reducing goals, processes, lessons learned, and insights gained over the course of decades down to succinct statements of less than 140 characters is an exercise leading to clarity and insight. I enjoy it, find it useful... Twitter is a critical part of the daily routine.

While I tend to think most often about project management and software development, process improvement and the processes that lead to improvement are frequent subjects as well.

My interests are varied and numerous; I mentioned a few (above and below) but won't list them all here. I tweet, on the average, anywhere from 6 to 20 times a day during the week; usually less on the weekend. I re-tweet about half as much as I tweet. I also @reply and @DM but not as often as I tweet and re-tweet.

I participate but I won't clog your pipes.

I hope you find these distillations entertaining, informative, and useful if you chose to read them.

The Follow

Typically, I follow people on Twitter because I find them personally or professionally interesting. Sometimes because I think they may prove helpful in some way with problem solving... or potentially so. Other times because of association -- geographic, interest in music, or the like. Conversations with others leads to growth, knowledge, understanding, and the potential for reciprocity.

Typically I find most interesting the thoughts of others offering clarity and insight within the 140 character boundary... on life, work, whatever.

Since I am an IT Project manager primarily involved in software and web development, I have an affinity for those of similar nature, in related endeavors, as well as people and organizations to which project management is a part of the solution. Because I work in PMOs and play a role in IT governance, I have an acute interest in management and governance in addition to PMI, the role of project managers in general, and the processes related to project management. Even though I am "in technology" I am not an uber-geek but I respect and like them.

Most of the time if someone follows me on Twitter I follow them back... but not always. Most of the time people who follow me find me of interest for the same reasons (stated above) that I find others of interest and wish to engage in conversation. That means we have something in common and I'll probably follow... and engage in that conversation.

I am not on Twitter to become someone's "target market" anymore than I have a telephone so sales trolls can more easily ambush me about vinyl siding or vehicle warranties. I also skip commercials on television and throw away junk mail and catalogs without reading. If I want something you sell, I'll find you myself.

It's not about "love," tweeple. Love has nothing to do with selling the newest version of vinyl siding, vehicle warranty, or marketing the "SECRET key to success" website. If you want to "love" me, then quit calling; stop clogging the pipes with your effluvia... kill the infomercials. I won't follow you and, if you persist, will block you and also report you for spam.

I follow a lot of people that once seemed of interest but are no longer in that category. Most of those are internet marketers... some of them really big names with followers in imaginary numbers. The reason that these people lost my interest is because they are repetitive. After a few weeks, I've seen their "message" and nothing new is forthcoming. They drop off the radar pretty quickly.

Advice: Keep it fresh and keep the self-promotional garbage down to near zero. If I want Spam, I can find it in the grocery store.

The No or Un-Follow

I usually do not follow anyone with a profile containing:

• Protected Updates
• No posts and thousands of followers
• No photo or an obvious fake photo
  
• No real location (e.g. "somewhere in the world")
  
• No real name (unless you are CNN or Apple)
• No bio, meaningless gibberish in bio, obviously fake bio
• References to yourself as "funny," "interesting," or "intelligent"
  
• Anything remotely resembling pornography
  
• Profane or foul language
  
• Any of the following buzz words or phrases
  
  • Guru
  • Network Marketing
    
  • Affiliate Marketing
    
  • MLM or Multi-Level Marketing
    
  • Internet Marketing
  • Work at Home
  • Law of Attracting
  • Personal Branding
    
  • Psychic
    
  • SEO
    
  • FREE
  • Want more followers?
  • The Twitter Trick (or any variant)
    
  • Fitness and weight loss
  • Slowing/reversing the aging process
  • Debt Reduction
    
  • Your success is my number one priority (or anything similar)
    

Anyone who tweets

• Way too much -- (broadcaster)
  
• Way too little -- (lurker)
• Repetitive content - same tweets over and over (broadcaster, junk)
  
• Only URLs (links) without commentary
  
• Only self promotional (junk)
  
• Consistently boring or inane (junk)
  
• Nothing relevant (junk)
  
• And never replies (broadcaster)
• With more than one exclamation point per word
• About nothing but how to use Twitter
• Nothing but Re-Tweets (a broadcaster with nothing to say)
  

Are you on that list?

If so, there should be no surprises (setting expectations here): I will not follow you.

Continual, multiple follow requests: When I received your first follow request, I checked you out. I reviewed your profile, read your recent tweets, and visited your website if you have one listed. I'm looking for reasons to follow you. I do this with all follow requests; I take them seriously.

If I didn't follow you back within 24 hours, it's because there is a good reason... probably one of those listed above. Your second, third, and subsequent attempts (on a daily basis) simply validate my initial conclusion and add an additional reason not to follow. You are now nothing but spam in my inbox.

I will block you. Where appropriate, I will report you for spam, porn, other illegal activity, or violation of the Twitter rules.

Turn your bots off and get real.

Wrap it Up

Some people become upset and irritated that I unfollow or refuse to follow them. That's OK, it's simply justification, in my opinion, that I did the right thing. If increasing your follower count Or "tweets for cash" is more important than conversation, then that is reason enough to avoid you. If something I tweet annoys a follower, if they find me inane or boring, or there's something in my profile they just don't like, I believe they are perfectly justified in unfollowing or not following me as well.

Less, not more, irritation is needed in our lives: Both yours and mine.

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.

Internet Privacy: The Raptors of Regulation

"Companies that track consumer behavior on the Web for targeted advertising without proper consent are near their 'last chance' to self-regulate." ~ FTC Chairman Jon Leibowitz, Monday 26 April 2009 at the Reuters Global Financial Regulation Summit.

Privacy Advocates

Privacy advocates have long knocked, unheard or largely ignored, on the doors of internet giants like Google and AT&T. These same advocates have a strong presence in Washington, lobbying Congress for change. Their basic argument is that privacy regulations are too lax, allowing internet companies to collect and use what advocates characterize as "private data" without notification, permission, or an opt-out.

The attention -- huge and growing larger in Washington -- is largely focused on "behavioral advertising." The push is to increase both privacy protections (permissions and opt-out) as well as transparency (clear, visible privacy policies). In a congressional hearing last week, Rep. Rick Boucher (D-VA) promised, by the end of the year, some form of legislation from congress to address the issue.

The Debate

This debate is taking place despite the fact that no one on either side can point to any specific harm done to consumers or internet users. Both sides admit the benefits (targeted and free content). The issue seems largely focused on a lack of understanding or confusion on the part of internet users... Users are unaware of when and how, or sometimes if their personal behavioral data is collected or used.

There are also clear signs in the way the debate is being framed in Washington that the government would rather not step in with regulations, preferring the industry to do so on its own. There is time, but very little left, for the industry to do so.

"If companies fail to do a better job of making their privacy policies understandable to the average person, momentum will keep building for greater regulation," Leibowitz said. “It’s really up to industry.”

Wrap It Up

A fork in the road is clearly here for internet companies and internet technology providers. The industry has only a few months wiggle room before choices vanish and the raptors of regulation descend. Google in particular has a chance to lead the pack and set the pace for the rest of the industry or defer and face the whims of the raptors.

Choose wisely: The time is now.

Subscribe

Project Manager: Building Pencils?

There is a tendency among some organizations to demand highly specific experience and qualifications in hiring project managers. In some cases this makes sense as specific domain knowledge may be appropriate and lead to decreased ramp-up time. When taken to extremes, however, the value is quite arguable, potentially negative, and raises doubts about the organizations' understanding of project management.

For example, one posting (found via Google search today) for an IT (technical) project manager included in the requirements a PMP (Professional Project Manager) certification as well as technical (hands-on coding) certifications in Java, J2EE, Oracle, SQL Server, Unix, VB, .NET, and ASP. A Bachelor's degree is required with a preference for a Master's degree and 2 - 6 years working experience in IT. This is, admittedly, an extreme example but serves to make the point and it is a real posting.

Certification Silly

Someone in the organization doing the hiring for that position is remarkable unclear on certifications. The PMP credential, for example, requires 5 years documented, verifiable project management experience (+high school diploma) or 3 years documented, verifiable project management experience (+Bachelor's degree) plus 35 hours of accredited project management education within the past year in order to qualify for the four-hour, multiple choice exam.

That is only the minimum needed to qualify for the exam, not what is needed to actually earn the credential. Many candidates take the courses, study for and take the exam multiple times before receiving the credential.

Credentials or certifications in the technical areas listed above require training, and testing and may also require experience. At the minimum experience level listed (2 years in IT) it is unlikely that that more than one or perhaps two of the technical certifications could be achieved. It is obviously impossible to earn the PMP credential in that time since, even with a Bachelor's, three years experience in project management is required.

At the maximum experience listed (6 years in IT), it is still highly unlikely that all qualifications are met by a single individual... not impossible, but extremely unlikely. For one thing, the probability of finding all those technical skills in use by one individual at one organization at the level needed to achieve certification within the given time frame is just off the chart. For another it's difficult to actually hold a full-time job while training, studying, and sitting for all those exams.

Beyond the extreme, obviously fantastical postings like the one above, there is a more serious point in all this. Take for example a more common requirement seen with some regularity: "IT Project Manager with recent Java certification and hands-on coding experience." This is not uncommon and raises several questions about the organization, the project, and the job itself.

The Job

First, look at the job itself. A project manager assigned to a large effort, or a couple of medium efforts, or 4 - 5 small efforts is fully engaged -- 100%+ -- in just doing the basics required of project management. It's 40 - 60 hours a week; maybe more at times. Where does writing code come in? How does writing code become a project manager's task?

Answer: It doesn't, and, it doesn't.

Domain knowledge is useful... even critical at times but that does not mean what some organizations seem to think it means. A software development project manager who completed numerous successful projects over the past few years with a verifiable background and references is superbly qualified to manage similar projects. If they spent the past few years writing code, they were not a project manager (someone else was) and are not qualified.

The Project

Second, look at the project. If code is being written by someone called "the project manager," then they aren't the project manager and someone else is managing the project. The project may be "all about" writing software but managing the project isn't.

Who's writing code for this project? Where are the programmers? The analysts? The technical "lead?" Are there no experienced hands on deck for this project?

If the coders on the project team require coaching in their programming language, that means there are no functional or team managers capable of providing this support. The organization should hire team managers and get their house in order before embarking on this project.

Analysis of the project from the posted job description for the project manager shows this project is doomed. Roles are poorly defined, the scope is not clearly understood by the stakeholders, the project goals are misaligned, the right resources are not on board, and functional management is non-existent or incapable of supporting the effort.

The Organization

Third, look at the organization. Organizations who expect project managers to compile code are not looking for a project manager. They're looking for a lead developer, team lead, or combination functional manager and project manager. The organization is, therefore, confused about the value of project management as well as the role of programmers, analysts, developers, and line managers. They are more than likely confused about other things as well.

With the notable exception of start-ups where one person is filling many roles in the nascent organization, roles become more specialized for a reason: The role requires full-time focus and specialized skills, experience, and background for success. Organizations ignore this axiom at their peril.

There are other possible explanations from the organizational stand point. For example, they may not, in fact, actually want a project manager. The organization needs someone to assume the title so the organization looks good in an audit or so executives can say to their Board of Directors, "Yes, we're using Project Management best practices... look at all our project managers!" In any event and regardless of the rationale, success is unlikely for the project, the executives, or the organization using this tactic.

Wrap Up

How many job descriptions for Graphic Designers say "Must have three years experience building pencils?"

How many times while interviewing a building architect does the question come up, "When was the last time you made a brick and where did you get your certification in brick making?"

How many times does a job description for a plumbing assistant require, "experience building pipe wrenches?"

Does a sales person for a liquor distributor need to be able to run a distillery? Grow grain?

When these kind of requirements are put in the context of job descriptions or roles with greater general understanding, the oxymoron becomes obvious.

Domain knowledge is one thing -- understanding the structural characteristics of different grades of brick for an architect or builder; understanding the architecture of .NET applications for a project manager -- but going to the extreme lessens the value received and increases the risk of project failure greatly.

Subscribe

Social Media for Project Managers

One of the biggest challenges in the project world has been and remains communications -- poor communications defeats otherwise excellent project teams. While more communication is not necessarily better communications and overlooking the needs of target audiences in crafting specific communications is certain disaster, social media of all types provide a real-time, powerful tool to PMs, stakeholders, and project teams.

In much the same way that web enabled tools like email, tele/video conferencing, VPN, and IM have been used in the past to facilitate virtual teaming, social media tools present the promise of greatly enhanced community, continuity, and collaboration through communication within teams. It is already doing so in our social, marketing, and business lives.

The power of Twitter, as one example, lies not only in real time conversation but in its search capability. Hash tag, keyword, and @ searches of both current and past twit stream allow users (and project managers) to see specific data, set up alerts for specified content, and coordinate or integrate results. Team members or stakeholders using #status, #issue, #[WBS item], #[project name], and @projectmanager are some examples.

Wikis for projects hold great promise in opening the door to real, usable lessons learned in the enterprise. If set up and managed correctly, this kind of wiki becomes a living repository for project information about what works, what doesn't, and how to fix it when it goes wrong.

What if everyone in the enterprise had a blog and knew how to use it? Projects with blogs, comments, and feeds are not uncommon -- a blog may become the status report or burn down chart for anyone with access. Content can be pushed to subscribers and comments allow interaction. Single entries can be printed to PDF for archiving. Properly indexed blogs (keywords) are searchable.

Some projects with widely distributed teams have used Facebook successfully. In addition to the personal status updates on Facebook, there are many choices of tools either built-in or available as add-ons.

Tools such as Ping.fm and others provide a single interface for posting to all media -- blogs, Twitter, or Facebook and can be a source book of all postings.

Public SM tools, however, are probably not for projects. Organizations should set them up in their own environment, behind company firewalls. Accessible for team members is via intranet, VPN or whatever secure protocol is in use. Public posting of project information is dangerous, probably violates company security policy, and may be a huge liability.

That said, SM provides an real-time, powerful, interesting and valuable set of tools for project managers and teams. Community, continuity, and collaboration through communication is the future.

Subscribe

Power Grid Going to NSA

Interesting article on Wired about cyber security and the power grid.

Those impish Chinese government cyber-saboteurs we last saw posing as 20-foot high trees to trigger the 2003 northeast power outage have returned in an all new adventure, this time in the pages of the Wall Street Journal.

Read More on Wired

Posted using ShareThis

Subscribe

Quotable: 20090402

A little risk management saves a lot of fan cleaning. ~ Anon

Subscribe

Quotable: 20090331

Common sense and a sense of humor are the same thing, moving at different speeds. A sense of humor is just common sense, dancing. ~ William James

Subscribe

How Business Does Twitter

CoTweet says it is "how business does Twitter." The start-up is in private beta now with some big names on board. Best Buy, Ford, Hershey Entertainment & Resorts, JetBlue, Intuit, Meetup.com, Microsoft, PepsiCo, Robert Verdi, Inc., Rotary International, Sprint and Waterford Wedgwood USA are using the tool now, providing feedback, and in a program (CoTweet Cohorts) to advise CoTweet.

CoTweet is built around a combination of CRM and a dash of marketing -- focused on positioning itself in the SM branding wars -- but information in a recent Mashable article indicates CoTweet is very close to workflow integration capability. It has some interesting features in that area now. This opens the application to many other uses and may foreshadow the path of further development including service applications.

Seems hopeful.

What do you think?

Subscribe

I Just Got Fired

This SlideShare Presentation sets a high standard in interest and appeal. Worth a look especially if you are job seeking now or expect to be in the future.

--Highly recommended

I Just Got Fired

View more presentations from jasonalba.

Subscribe

Quotable: 20090316

Posted by: William W. (Woody) Williams

I had to make some optimistic assumptions to meet the revenue target. In week three, we're visited by an alien named D'utox Inag who offers to share his advanced technology. --Dilbert

Subscribe

Sign Up Now!!! Technology Showcase

Posted by: William W. (Woody) Williams

Central Texas has a long and colorful history and some of that history includes technology. Central Texas is an area centered around Austin. From San Antonio to the south and north to Round Rock, and Temple. The area includes numerous giants like Dell and IBM with hundreds of smaller tech outfits and start-ups.

There's a set of skills, a creative spirit, and an entrepreneurial talent pool in Central Texas that blends well with the rugged Texas Hill Country and Highland Lakes. It's a hot bed of high-tech start-ups... a not-so-west-coast version of Silicon Valley.

door64 -- a Central Texas High-Tech Community is organizing a showcase for technology related companies to be held in Austin on April 30, 2009. These people have an outstanding track record for putting on amazing events. You and your company should be there.

Matt Genovese, door64 founder, says, "The goal of this event is to showcase Central Texas technology companies, and help them gain exposure in the local tech community. With such exposure each company may discover new customers, partners, hiring candidates, suppliers, investors, etc."

All 4000+ members of the door64 community, and 7000+ members of the LinkedIn group will be invited. Besides engineers from around the Central Texas area, other groups of individuals and organizations will be invited (e.g. angels/VC's, etc.)

Prior to the Tech Fair, your company will be promoted on the the event web page so attendees know you will be there. At the event, your company will be provided a table, two chairs, and signage. Within reason, you may bring whatever materials or promotional items you wish! This is your opportunity to showcase your business to the local tech community, so demo yourself!

We are holding the door64 Tech Fair on the same date/location as the IEEE 125th Anniversary / GACC Brain Party held on Thursday, April 30th in Austin, Texas. So immediately after the Tech Fair there are plenty of activities planned, including a panel discussion, and the party. So make plans to stick around and continue to network after the Tech Fair!

If you own, manage, or are employed by a technology related company in the area or if you simply would like to attend this affair, check out the details on door64 here: door64 Tech Fair.

Subscribe

Quotable: 20090315

Posted by: William W. (Woody) Williams

In every marriage more than a week old, there are grounds for divorce. The trick is to find, and continue to find, grounds for marriage. -- Robert Anderson

Subscribe

Free Webinars with PDUs

Posted by: William W. (Woody) Williams

Two great sources for free webinars offering PDUs.

International Institute for Learning:

IIL’s free 1-hour webinars cover the latest topics in Project, Program and Portfolio Management, Microsoft® Office Project and Project Server, Lean Six Sigma, Business Analysis and more.

ITPMI -- The 2009 Software Best Practices Webinar Series

The Software Best Practices Webinars Series is dedicated to improving the practice and management of software development and maintenance world wide. All live webinars are FREE and have been accredited with PDU credits by PMI's ISSIG group. Each webinar is worth 1 PDU credit. Topics covered in 2009 will include:

• Software Measurement
  
• Software Project Estimation
  
• Software Testing
  
• Software Project Management
  
• Software Benchmarking
  
• Rapid Application Development
  
• Legacy Systems Support
  
• Agile Development
  
• Software Six Sigma
  
• IT Project Governance
  
• IT Infrastructure Library (ITIL)
  
• Outsourcing Best Practices
  

Thanks to Nancy Shindler, PMP of the Austin PMI Chapter for passing these along via Austin PMI Discuss.

Subscribe

Sometimes Documentation is Everything

Posted by: William W. (Woody) Williams

An attention grabbing news story: Text quoted below scrapped from Fox News but same story / text available from most media outlets.

The Department of Defense and the National Nuclear Security Administration had to wait more than a year to refurbish aging nuclear warheads — partly because they had forgotten how to make a crucial component, a government report states.

Regarding a classified material codenamed "Fogbank," a Government Accountability Office report released this month states that "NNSA had lost knowledge of how to manufacture the material because it had kept few records of the process when the material was made in the 1980s and almost all staff with expertise on production had retired or left the agency."

Short story is: "kept few records" exacerbated by, for various reasons, no one with knowledge of the process on staff.

To recover, it took a year, a large project team, and a lot of money recreating the lost production process -- tax dollars wasted because a single file was never saved. The cost of rework decades after the fact is a lot more than the tiny cost of producing and archiving a few documents the first time through.

Not every project produces a product as critical or dangerous as a nuclear weapon. However, in this case the point concerns a production process, not the delivery of a warhead or the firing of a missile.

That undocumented production process is one we knew or should have known would be required in the future. Maintenance is an ongoing requirement in almost any system -- especially systems with expected life times in decades. "Transition to support" is a well defined process followed in every product lifecycle and always involves the sharing of maintenance knowledge.

Hairs may be split over whether or not a particular set of documents amounts to knowledge but, in this case, neither documents nor knowledge were retained. This is a grievous error in judgment and project planning.

Product and project managers, as well as their teams, take heed. Whether we refer to it as "documentation" or "knowledge management," there is a clear lesson.

There is a small upfront cost to planning and knowledge management (or documentation). It is worth it.

Subscribe