Difference between Change Control and Configuration Management

Project Management Professional (PMP) students often confuse Integrated Change Control (ICC) and Configuration Management (CM). To put this very simply, ICC controls change whereas CM controls the records of all approved work.

Configuration Management

There are two types of changes. One moves forward whereas the other move backward or sideways. (The are not PMI terms. I use them just to help you picture the differences.)

Forward change is normal work as it happens according to plan. You submit the Project Management Plan and ongoing work to CM when they are done and approved by reviewers. The main purpose of CM is to make sure everybody bases new work on the latest, approved plans and work.

CM also provides and controls the repository for work history, process assets, and lessons learned. Once work has been approved and entered into CM, it becomes subject to change control.

Integrated Change Control 

Backward changes revise work already done. Sideways work requires changing the Project Management Plan or design plans before moving forward. All changes to the plan or to previous work go through ICC. The ICC procedure ensures that you consider the alternative measures and the effects that a change can have. Passing the change through the ICC Board ensures that people with various perspectives can identify stakeholders and impacts you did not think of. This procedure enables making informed decisions.

The change request and the ICC Board's decision are stored by CM. If the change is approved, the change has to be implemented, and the records of the change (for example, approved, revised documents) are stored by CM. CM usually has responsibility for notifying the stakeholders in accordance with the communications plan.

Think of the ICC as the process for making sure changes to existing plans and work are done the right way. Think of CM as the library where all approved plans and work, including changes, are stored.

The Plausibility Trap

Have you ever accepted a perfectly good explanation for an issue or solution to a problem and then learned later that it was wrong or less than best? You may have stepped in a Plausibility Trap.

You might be looking for the cause of a problem, the way to fix a problem, or an inconsistency that discredits a book. You find an explanation or solution and commit to it. Later, the solution does not fix the problem. Or somebody offers a different explanation that's infuriating because you cannot find any flaws with it and it makes your explanation sound stupid (even though you just know you're right). 

Plausibility Traps Everywhere

Root Cause Analysis helps overcome cognitive bias and plausibility traps by teaching you to look at different facets of a problem before making any decisions. We might want to blame the input to a process, but the environment, another input to the process, the purpose itself, a detailed step in the process, or even a recipient of the product might contribute to the problem. 

We get rushed, however. We fail to discipline ourselves, and seize upon the first solution we think of. We don't weigh possible causes against each other or look into the cause-behind-the cause. 

Tools for Avoiding the Traps

The most critical attribute in decision-making the ability to balance openness to more evidence and possibilities against the pressure to make the decision.

One solution is to use a graphical method such as mind-mapping or fishbone ("Ishikawa") diagrams. They force us to think about different types of influences, and then for each type, what secondary influences could go wrong. 

You can start with a standard list or create your own. For example, manufacturing has the Eight Ms:

• Machine (Technology)
• Material
• Measurement (Inspection)
• Management (Money power)
• Maintenance
• Mother nature (Environment)
• Man power (Brain work)
• Method (Process)

Business Management has PEST Analysis:

• Political
• Economic 
• Social 
• Technological

Each of category above has multiple sub-categories that are outside the scope of this article.

Another tool is the Five Whys. Get an answer to Why? and then ask Why? again. And again. And gain and again, until you arrive at a cause that is not under your control. "Five Whys" is the Americanized version of a Japanese expression, why-why. You go as far back as the first cause that is not under your control, and then respond to the first step that is under your control. 

The beauty of Five Whys is that things that go wrong tend to cause multiple problems. So if you prevent or mitigate that root cause, may you fix other problems you didn't eve know about.

Once you've identified several solutions (or causes, explanations, or steps), you may find that more than one are needed. Here's where you evaluate how likely each solution will help and how much it will help, and then choose not just one solution, but as many as it takes to address most of the challenge. Here, tools such as decision trees, the 80/20 rule, Pareto diagrams, and Tornado diagrams can be useful. 

Examples

Here are two examples from outside business where the people fall into plausibility traps. 

1. The news carries an account of a police officer shooting a suspect. One group leaps to the conclusion that the incident exemplified a racist America and incites people to riot. Later, it turns out that none of the objective facts supported the first group's conclusion. 

2. Somebody reads two accounts of an event or policy in a holy book and concludes that the differences prove the event never happened. Another person considers several ways the two accounts might be reconciled, and one of those ways rationalizes all discrepancies. The first person fell into the plausibility trap by accepting the first explanation that came to mind instead of searching for ways to merge the accounts. The second person realizes that, if the two accounts can be rationalized, then you cannot say they are untrue.

We don't want to fall into "analysis paralysis," but we don't want to fall into the trap of  simplistically accepting the first "plausible" explanation or solution, either. The more important the issue, the more facets and layers you should consider.


Copyright 2018 Richard Wheeler

Project Manager and PMP Candidate Resources

I will add resources to this list as I come across them or as you identify them in your comments.  With my budget, the emphasis will be on free resources.

Webinars

• Peter DeJager and Technobility offers live webinars and a library of dozens (free, but donation requested)
• ITMPI offers several webinars per month. The webinars present high quality materials and are free, but they charge for the PDU codes unless you join. They also have a library with hundreds of recorded webinars for a fee.
• The Human Capital Institute 
• http://Reflektive.com 
• http://ModernAnalyst.com 
• http://ProjectTimes.com 
• http://ProjectManagement.com/ is associated with PMI.

Podcasts

• Elise Stevens @ElisethePm
• Lean Blog
• People & Projects
• Gemba Academy
• Mastering Business Analysis
• PM for the Masses
• http://Manager-Tools.com

Sample Questions and Mock Exams

- Beware outdated content. Don't waste your time with any mock exam whose site does not clearly identify it as based on PMBOK 6.

• Edward Designer's list of free mock exams
• Oliver Lehmann's list of thousands of free mock exam questions -- Scroll to the table at the bottom 
• 100 Online Questions from Oliver Lehmann -- Scroll to the bottom for a table listing thousands of free questions -- Some links may have outdated questions.
• 200 Offline Questions from Oliver Lehmann -- PDF
• Free PMP® Exam Simulator -- Cornelius Fitchner's free 200-question simulator, 7-day access
• PM Aspire PMP Simulator -- 2 free simulated exams X 200 practice questions, 5-day access; Singapore-based, so the English might not be the best

PM Social Media Communities

- The lists below are in no particular order, and my listing of any group does not necessarily constitute a recommendation.
- Study tip: When studying sample questions posted online, look up the answers in the PMBOK and explain why the best answers are best and the other answers are less than best. Having to form complete thoughts helps you internalize the material and helps others learn, too.

LinkedIn

• The Project Manager Network -- 867,000 members; managed by Recruiter.com
• Project Manager Project Manager Community -- 366,000 members
• PMI Project, Program and Portfolio Management -- PMI's official LinkedIn group
• Project Management Professionals PMP
• Project Management Link - PMLink
• PRINCE2 & MSP - Project & Programme Management + Agile Scrum
• Project Management Group SP -- What does the SP stand for?)
• Construction Project Management 
• PM Community - Product/Portfolio/Program/Project Manager

Google Plus

• Project Management, PMI, PMP Certification -- The most active PM community
• Project Management Community -- Less active, but great posts
• Sensible Project Manager Hangout -- Discussions, with recordings available
• Project Management Masters -- Great posts, strict moderation

Facebook

- Requests for stolen IP are rampant in some of the Facebook groups. Please join me in discouraging it.
- Some sellers of test materials post the same sample questions in many PMP study groups, and their questions dominate the less-active groups; so many of the groups add little unique value.

• Professional Project Managers -- Joseph Phillips' group; Phillips has an exellent, low-cost exam prep course on Udemy.com 
• Project Management Café -- Elizabeth Harrin's group (author of Girl's Guide to PM)
• PMP Study Group - with Expert Professionals -- less than 1,000 members, but lots of mock exam questions and no spam
• PMP Tricks -- Based in Saudi Arabia; mixture of languages; 6,200 members
• Pmp Exam Preparation -- over 7,000 members, mostly exam questions
• PMP Study Group 
• Project Manager
• Project Management Professional (PMP) Study Group
• The Project Management PrepCast -- Cornelius Fitchner's promotional page offers occasional free content
• I want to be a PMP® - (PMI Project Management Professional Certification )
• Project Management -- Not sure this group is legit
• Free Project Management Books and Knowledge, Prince2 and PMP Exam Guidance -- Despite the title, I haven't actually seen much IP theft in this group
• Construction Project Management & Contracts Books 
• PMI - Project Management Professional PMP -- Does not appear to be PMI's page
• Project Management
• PMI / PMP Project Management Focus Group 
• Project Management Professional (PMP) -- Admin'd by Maples Project Management
• Project Management Library 
• PMP - A Project Manager's First Step -- 17,000 members
• Project Management Professional PMP study group- Progress PM -- 10,000 members
• PMP Egypt - Project Management Professionals in Egypt 
• Oil & Gas Project Management Group 
• Jobs for Project Managers: Career and Job Forum 
• Project Management and PMO: Courses, Training and Mentoring -- The blog of the Sheldon Institute of Project Management
• Professional Project Management -- 3,700 members
• Construction Project Management -- Based in Iraq; 12,000 members
• Your Dream Project Manager Job - Career Coaching For Professionals -- Sage words from Luis Peluffo
• Project Management Lets Share Tools and Ideas 
• Online Hub for Virtual Assistants & Project Managers 
• How to pass PMP exam? 
• PMP Exam Study Group 

Future Additions to This Page or New Pages

• Business Analysis Resources
• Continuous Improvement Resources

When Sales Promises Phantom Features

What should a Product Development or Project Manager do when Sales has sold the product with a feature that does not exist, Engineering does not plan to build it, and it is not in the SOW?

This is like bringing the boss home for dinner without telling your spouse.

In this case, the organization is broken. It is stovepiped, with Sales not considering other stakeholders within the organization.

Some would look at the Statement of Work (SOW) and draw a hard line, but that option often does not legally exist. The spoken word often binds the Seller.

My answer assumes traditional product development and project management. Agile developers have considerable flexibility with scope.

If you don't have a Change Management Process, create one. Your Product Roadmap, Project Management Plan, and product design may require significant rework that must be analyzed and documented. The presumptuous defenestration of all that planning incurs significant costs and delays because they have just altered your carefully optimized route.

Driving is a great metaphor, here. You invested significant creativity and expense in planning to add features and develop your market in a logical order. Now, you have to spend more budget and time on planning a new route that may take longer to get to the destination.

As a starting point for accountability, require Sales to submit a Change Request form that requires documenting the business case, costs, funding sources, risks, schedule impact, and technical impact and feasibility. This requires business analysis and coordinating efforts of many stakeholders such as the buyer, users, Product Development, Engineering, Production, Deployment, Scheduling, Contracts, Finance, Quality, and suppliers (through Purchasing). The change may be a "done deal," but Sales needs to stand before a Change Control Board (CCB) and gain an understanding of the consequences of their actions. When the borrowed experts from Engineering start charging against Sales' budget, even their managers will get the message.

Fulfilling the changes will require a combination of creative options.

• Most people will compromise rather than spoil their relationship with your company by taking advantage of a loose-lipped salesman; so you may be able to negotiate a change to the contract based on re-prioritizing client needs.
• Since the change may have value to other customers, management might accelerate investment in product development funding.
• Consider dipping into Management Reserves and profits.
• Bring in a Lean/Six Sigma team to find cost and schedule savings. (After that, have them help fix those stovepiped processes.)
• If the Product Roadmap includes features not delivered to this customer, delay their development.
• Look for features planned for the product but not promised to the Customer. They may be removed.
• Sometimes, the penalties for breaking a contract cost less than fulfilling it. This is your worst option, but it is a valid option.

A well thought-out Change Request Form anticipates the areas that require investigation when instigating change. A well-designed Change Control process not only provides opportunity for characterizing changes, but also for creative thinking about the solutions to sticky problems. 

Copyright 2017 Richard Wheeler

Two Steps toward Making Stakeholder Management Manageable

Two Steps toward Making Stakeholder Management Manageable

The materials I've found about Stakeholder Analysis have not explained much more than the PMBOK Guide explains. What grids other than the Power/Interest grid tell me remains a mystery.

However, I have found two hints that simplify the whole Stakeholder Identification (and Analysis) process.

Divide Stakeholder Analysis 

PMBOK 4 describes Stakeholder Analysis as a single Tool/Technique. I would split off the elicitation of information as a separate technique and call it Stakeholder Survey.

Use a form as you visit around the office eliciting detailed stakeholder information. Transfer that information to the Stakeholder Register at the end of the day. If you put the register on a server and can access it register through Wi-Fi, you can save on data entry time.

Fill in what you can before bothering stakeholders. Then verify that information and elicit the rest, as much as you can, face-to-face. For what remains, you can use a questionnaire.

Simplify through Progressive Elaboration 

Consider an analog in Risk Management: First, you use Qualitative Analysis to identify the key risks. Then you use Quantitative methods to analyze only the key risks.

Now, take these lessons from that model:

• You don't need to perform full analyses for all stakeholders.
• You need only a small subset of the information to start.
• Decide what information you need in order to identify Key Stakeholders.
• Use the Power/Interest grid to identify Key Stakeholders.
• Collect further information and perform further analysis only on the Key Stakeholders.

Increase the degree of Stakeholder Analysis through progressive elaboration.

1. First iteration: Key Stakeholders
2. High Power/Low Interest stakeholders
3. High Interest/Low Power stakeholders
4. Low Interest/Low Power stakeholders

Remember, subsequent iterations should require less information and analysis.

This may be as much a delaying tactic as a simplification, which is what I really wanted. However, reducing, breaking up, and delaying the work relieves some of the stress of a potentially overwhelming process.

3 Factors in Risk Management: Probability, Impact, and Velocity

Risk Score

Qualitative and Quantitative Analyses in Project Risk Management both take into account Probability (P) and Impact (I). A Risk Score is the product of the two.
Qualitative Analyses use subjective estimates of probability and impact as a screening process that categorizes risks for management, monitoring, or ignoring. Risks placed in the management category go on to Quantitative Analysis and Risk Response Planning.

What about Urgency?

A third value should be considered: Velocity (V), which is the inverse of the time-to-impact.
Seldom can we deal with all risks at once. The value of considering Velocity lies in prioritizing further effort so you have enough time to respond to urgent risks. We would not consider Velocity when assigning risks to the three categories because we want to deal with the important things, not the urgent things. (Consider Pareto's 80/20 rule.)
If Probability times Impact describes an area, then to be consistent, we would add Velocity as a third dimension. That is,
Priority Score = Priority x Impact x Velocity

Another View of the Priority Score

Priority times Impact has another label, which is Expected Monetary Value (EMV). EMV is often used by itself for guiding decisions. If we express the Priority Score as
Priority Score = EMV x Velocity
then we give EMV a weight equal to the weight of Velocity.
The reason we would not consider the Velocity by itself goes back to the principle about the cost of rework. The later you deal with a problem, the more it costs because you have to repeat and fix work that came before. The previous effort becomes wasted, costs rise, schedule lags, and you have to use extra resources to get back on schedule.
Similarly, the longer you wait to deal with a risk, the more rework you have to do. Therefore, we need to factor both Velocity and EMV into prioritizing work: Velocity to deal with urgent risks, and EMV to control costs.

A New Step: Priority Analysis (when needed)

I recommend inserting a new step into Risk Management when there are risks with high velocity and you have to prioritize which risks to deal with first:

1. Qualitative Analysis with Risk Score = estimated Priority x estimated Impact
2. Priority Analysis with Priority Score = EMV x Velocity = Priority x Impact x Velocity
3. Quantitative Analysis with Risk Score plus other factors such as Velocity and Cost Effectiveness

I bring up Cost Effectiveness because you want to ensure that you don't spend $150 to prevent a risk whose EMV is only $100.

Reference

Hall, Harry, PMP, PMI-RMP. 30 Quick Risk Evaluation Tips. PM South. http://www.pmsouth.com/2015/07/18/30-tips/. Accessed 21 July 2015.

The Black Hole of the Agile World: Systems Thinking

Agile fanatics (excuse me: practitioners) love to do things in tiny increments.

That's OK for products where bite-sized deliveries have value, but it's fantasyland for many real-world projects.

Take, for example, the design of a new car. Sure, you can break the car into systems -- chassis, body, safety package, motor, and so on. Waterfall does that, too, but let's consider the airflow over the body. The airflow is affected by the whole assembly. Every part affects the whole. You can't just design a fender in isolation and say, "Looky, looky, I've delivered value!" No, you've delivered an irrelevant piece of scrap.

In any course on Business Analysis, the importance of a unit on Systems Thinking cannot be overemphasized because the Agile world has completely forgotten its value. 

Before the 1990's, there was a role called Systems Engineer.

That title is still around, but the job is not. At least, the job has become a rare grain of wheat a vast field of tares.

A Systems Engineer had many skills of a project manager, a BA, a Systems Thinker, and a cross-disciplinary engineer, all rolled into one.

Along come companies such as Microsoft and Cisco, dropping the qualifying word from titles such as Network Systems Engineer, Software Systems Engineer, and Server Systems Engineer. Suddenly, every engineer, analyst, and administrator is a Systems Engineer. I wish I had a paycheck for every time a recruiter has contacted me with a so-called Systems Engineer job that turned out to be for an IT admin or a software coder.

True Systems Engineering jobs have become needles in a field of haystacks, and systems thinking has almost been forgotten.

Thousands of Systems Engineers lost their jobs due to decimation of the US Defense sector in 2009. (I proud of myself for not pointing out the predictable political element of that.) They still find three strikes against them:

1. Transitioning to a different job category such as Project Management or Business Analysis
2. Getting a foot in the door of a different industry (other than fast food)
3. Living in a job market where all the growth is in part-time service jobs and has gone to low-skilled workers

Hiring managers would do well to consider bringing in experienced cross-disciplinary, systems thinkers. It would not take much training to bring them up to speed in new roles such as PM or BA.

Have you ever thought of a project as a system of people, or a product as a system of technologies? Systems Engineers do that instinctively, and such integrated systems thinking could prevent a lot of headaches for maturing companies.

Now, if you'll pardon me; I need to clean up a spill in aisle five.

Trusting the Project Team

Vikas Gupta asks on Google Plus, pretty well answering his own question:

How much can/should a Project Manager interfere in the technical details of a project? For e.g. If a developer thinks that xyz is the most efficient way of implementing a functionality, is it unproductive for the Project team to have PM challenge that beyond a limit? I personally think that challenging the team members is ok, but a PM must trust the technical skills of team members and too much interference may demotivate the team.. Thanks in advance for your expert opinion!

 Discussion Link April 30, 2014

Project-Aria replied,

It is rare that a PM is just a PM.
Usually the PM also adds value by bringing technical expertise. Now the question here is: does the PM have the expertise in technical area in question. If yes, then yes. If no, then interference may be a dangerous path.
I would also note that communicate is a 2-way challenge. It is also important to all team members, including experts, to be able to explain their ideas and convince others. It is important for the expert to be able to communication without hiding behind a expert-cryptic language.

Apr 30, 2014

I think Vikas stated it well and correctly. Early in each design phase, the PM can ask the team to consider his personal favorite solution. The design team should then compare the various options for each architectural element and weigh them against each other. The result is a trade study that weighs the trade-offs and makes an objective recommendation of the best solution.

Unless the decision is very close, the PM should leave the decision to the results of the trade study. If he does not, it can reflect badly on him.

• It indicates that he did a poor job of selecting his team.
• It insults the design team and, as Vikas said, demotivates them.
• It may indicate that he failed to have the design team include his favorite option in the trade study.
• It may indicate that he failed to properly define the design parameters.
• It indicates subjectivity, a failure to rely on objective evidence produced by the trade study.
• It turns the time and cost of trade studies into waste.
• Failure to trust often results from projection; that is, expecting others to do what you would do. Therefore, it raises issues about the PM's ethics.
• Overriding the results of a trade study can create an appearance of impropriety (for example, the PM appears to take a bribe from the selected vendor or subcontractor).

As Project-Aria stated, the PM may bring enough technical expertise to deserve the right to override the design team; but he had better have convincing technical reasons for his actions and had better own up to his mistakes that made his action necessary.

If your experience has shown you more reasons why a PM should or should not override the decisions of his design team, I'd like to hear from you in the comments.

Training the Software Requirements Engineer

What are different type of training required for a Software Requirement Engineer?

The correct answer is, it depends. Software requirements training should fit with the type of project management used by your organization.

One type of training you don't need

Many people think a software requirements engineer should thoroughly understand programming and software engineering. Obviously, you should know something about the software engineering discipline, but knowing too much can destroy your ability to write good requirements. This happens for two reasons.

First, good requirements should ignore the technology (such as which platform or language is used). This is because requirements should not dictate the solution; they should only define the problem to be solved. Devoting too much study to the technology will bias a requirements analyst toward particular solutions. This makes consideration of alternate solutions more difficult for the design engineers.

Second, requirements elicitation is an art as much as a discipline. Managing stakeholders, conducting meetings, choosing elicitation methods, and choosing methods for representing information require strong skills in psychology and communication. Putting all your energy into learning programming languages and tricks will cost you on the human side. It would be as great a mistake as putting all your energy into market research. You need to know enough about programming to win the respect of the designers and to communicate with them, but your job is to build a bridge between the customer and the designer.

What should I wear? Well... where are you going?

Organizations that work with large systems that integrate multiple technologies tend to follow traditional Project Management and Systems Engineering methods. They use some variation of the Waterfall model, such as the V model.

For a high-level understanding of Systems Engineering requirements methods, I recommend starting with INCOSE's (International Council on Systems Engineering) Systems Engineering Body of Knowledge (SEBOK) and using the SEBOK as a guide to subjects for study. Also consider studying Model-Based Systems Engineering, one subset of traditional methods, and SysML, the modeling language used for MBSE.

Organizations that work primarily with software tend to follow Agile project management methods. In Agile environments, requirements engineers tend to go by the title Business Analyst. I recommend starting with the IIBA's (International Institute for Business Analysis) Business Analysis Body of Knowledge (BABOK) and using the BABOK as a guide to subjects for study.

Agile is a set of principles and not an actual method. I have asked for a recommendation for a book that describes the different methods (such as Scrum and Kanban) but have been told no such book exists; for each Agile method, you need to find a different book.

The requirements methods differ considerably between traditional and Agile. Traditional methods nail down requirements and then negotiate schedule and cost. Agile nails down schedule and cost and then negotiates, prioritizes, re-prioritizes, and drops requirements.

The two methods do share some of the same tools. I suggest studying Unified Modeling Language (UML). UML is not a language, but a set of graphical methods for defining requirements. The most commonly recommended book on software requirements is Software Requirements, 3rd edition, by Karl E Wiegers and Joy Beatty.

Classes for Technical Writers / Communicators

Any suggestions for what further education pairs well with technical communication?

-- Nicholas

Ask the Right Question

Nicholas has asked the right question -- sort of. I don't think anybody can answer the question for him.

 

A technical communicator translates the Subject Matter Experts' (SME's) geek-speak into plain human-speak. Learning the SME's language will play a pivotal role in success. Even introductory courses in the chosen domain will dramatically shorten the learning curve once he lands a job.

 

The question omits any decision about the domain in which Nicholas will practice. When he chooses a direction, he will be better able to determine the answer for himself.

 

If Nicholas has not chosen a domain, yet, I would suggest that he visit his school's career office and the state employment office and ask, "What industries show growth potential for Technical Writers?" Once he has a list of, say, the top ten fields, he can consider which field(s) would most personally reward him.

After that, he can ask, "What subjects would best help me learn the language of the SME's in that field?"

 

Supporting Skills

An employee does not just sit down and start doing the job. Each job has supporting knowledge areas such as planning work, reporting activities, conducting meetings, and defining and adhering to ethics. A successful employee also looks ahead in the direction that the career and the profession will take. That adds soft skills, management, and industry trends to the list.

 

I will name two of the most important skills Nicholas could add to his quiver.

 

First, the most important SME in anybody's career is the boss. Learning about project management (I suggest PMP Exam Prep by Rita Mulcahey) will help Nicholas:

• Understand how he can support his manager's success
• Learn more about organizing his own work
• Start his climb up the career ladder

The knowledge areas defined by project management standards can also serve as springboards into further studies.

 

Second, the ability to visually model processes and information would help Nicholas in any industry. To that end, he should familiarize himself with the Unified Modeling Language (UML). An Internet search will turn up plenty of tutorials.)

 

UML is not a language (not in my vocabulary, anyway), but rather a set of graphical styles and standards for defining and illustrating relationships between entities and for defining the processes in which entities interact. If Nicholas works in the software field or supports business processes, he will probably need to understand UML, anyway.

 

Basic Life Skills for Success in Any Technical Career

 

People normally associate project management with management and producing products, and they associate UML with software engineering, systems engineering, and business analysis. However, the set of tools these two topics would give Nicholas, and the ways of thinking that they teach, would be invaluable in almost any domain. He can study those areas while thinking about the industry he wants to work in.

 

"Professionals" distinguish themselves by continuously and independently learning. Schools lead students through semi-standardized curricula, but professionals write their own curricula. Nicholas should plan his future studies but bear in mind that:

• he will continuously update that plan, and
• he does not have to do all his studying now.

Change Request Analysis or Filing the Change Request -- Which First?

As sample question for PMI's PMP exam asked, in part, whether an analysis should be performed before "raising the change request." I believe that the PMI-approved answer is that, when somebody such as the customer requests a change, the first step is always to analyze the impact.

Defining the Change Request

The answer to this question depends on how one defines submitting, filing, or "raising" a Change Request (CR). If it means submitting the request to the Change Control Board (CCB), expecting its approval, then one definitely should perform the analysis first.

However, I define filing a CR as placing it under control of the CCB. That does not mean that the entire board oversees the CR before it has been analyzed. It means that the CR is entered into a Change Request Log so it can be tracked and analyzed with adequate oversight.

Preventing Duplicated Analyses

Performing the analysis before filing the CR implies that, if the request is not practical, the Change Request may never be filed. That can cause problems.

Suppose the customer suggests a change to the Chief Engineer, and the CE does an analysis of the change. Then the customer suggests the change to the Project Manager, and he does a separate analysis. Later, one of the engineers thinks of the same change and does yet another analysis. Do you see the waste?

To avoid such waste, an organization should have a coordinator act as gatekeeper for the Change Control Board. Each Change Request (CR) should be filed with the facilitator before an analysis is performed. The coordinator can cross-reference the change against previous CRs to identify similar or duplicate analyses that have already been performed. This prevents duplicated effort. The coordinator can also suggest other resources, such as studies or subject matter experts. Or, the coordinator might create efficiency by combining the analysis with another activity.

Tracking Progress

Now, imagine that the customer asks the PM to make a change, and the PM performs an analysis, but it falls off the PM's desk into the trash can and is forgotten. Later, the customer sues the company because it did not make the requested change.

Instead, imagine that the PM filed the CR with the CCB coordinator FIRST, before analyzing the impact. The coordinator would create an entry in the Change Request Log and assign a due date for the analysis. When the due date comes, the coordinator asks the PM, "where's your analysis?"

Objective Evidence

Later, if the customer asks, "Why wasn't that change made?" the PM can ask the coordinator to look it up in the CR log. The PM finds the file number of the analysis and sends a copy of it to the customer.

Controlling the Cowboys

One last scenario: Suppose the hydraulics engineering manager falls in love with a certain change. He takes a week to perform the analysis and then files the CR with the CCB. However, the CCB has a wider perspective and wants the analysis performed by the Mechanical Engineering director in coordination with Purchasing and Manufacturing. The second analysis takes another week. If the hydraulics manager had submitted the CR to the CCB first, they could have saved a week and gotten the change approved earlier, when it was less expensive to make.

Conclusion

The PMI answer may assume that you should not bother the CCB until you have analyzed the change. However, allowing the CCB to coordinate CR analyses can reduce analysis costs, save time, create accountability for completion of CR analyses, increase the quality of the analyses, and ensure that the analyses become part of the project records.

Put Off Blaming Procrastination

Work will always expands to fit the schedule.

Recent posts on the theme of procrastination, or more specifically, finishing work on deadline rather than early, have stepped on my toes. I'd like to speak up on behalf of my fellow "procrastinators."

The theme implies that people have nothing to do besides that One Task. It implies that they sit around playing games and don't have to scramble to meet multiple, simultaneous, arbitrary deadlines and then die inside when people criticize the lack of perfection.

On Time is Late -- Are you sure about that?

Before dealing with "procrastination," one should question the value of beating deadlines rather than meeting them.

The Lean principle of Pull states that early delivery can cause waste. Normally, one thinks of storage costs as waste, but doing work before it's needed presents other costs. For example, racing to complete a task might sacrifice planning, risk management, or quality. It might also cause neglect of lower-priority tasks or accelerated cost of funds.

The real schedule-waster is not procrastination. The great Time Thieves are multitasking and perfectionism.

The assignments will multiply to fill the schedule.

Multitasking eats up time by inserting course changes into the day. Human minds are not like Intel chips with four independent CPUs. It takes time to push task A into the stack, bring up task B, recall where you left off, and start making progress again. Moreover, what manager will forgive neglecting task A, which is due tomorrow, just so task B can be completed a day ahead of its due date one week from now?

The reach for perfection will stretch to the deadline.

Management teaches "procrastination" by forgetting to balance constraints. If you expect perfection in any human endeavor, expect employees to pour every available hour into quality.

Managers who want early deliveries need to increase collaboration with their reports. That means, first, avoiding micromanaging, but still sharing enough involvement to guide energies toward the right balance between progress and quality. It means, second, putting themselves in a position to say, "Stop! That's good enough," when the task reaches sufficient progress and quality.

The prevalence of multitasking and perfectionism make "procrastination" not a performance problem, but a management problem. Sure, when employees fail to adapt, it becomes a performance problem; but I caution against pointing fingers at the effects when the cause lies within Leadership's hands.

Make Lessons Learned a Part of Your Culture

An organization with process maturity will close the loop on Lessons Learned.

By closing the loop, I mean that the organization will ensure the capture, distribution, and institutionalization of the lessons taught by the school of hard knocks.

While the Project Manager should identify and collect Lessons Learned, Quality Assurance should categorize and preserve them.  QA should take further steps to communicate the lessons.

First, leaving it to everybody to go searching the LL database does not work.  Like that will ever happen! Ha!

Instead, QA should sort the LLs by function and subject and distribute the information to affected functional managers across the organization.  This ensures that, for example, the Integration Engineers in different programs and at different locations receive the expensively acquired knowledge.  If the functional managers fail to communicate the lessons to their people, upper management should give QA the authority to do so.

Second, QA should incorporate applicable improvements to the Organizational Process Assets.  This way, QA does not merely deposit critical knowledge into the Tribal Knowledge Bank, but actually institutionalizes it.  This introduces accountability when QA audits process compliance.  It also allows the lesson to be moved to a section of the database that lists rationales for historical purposes.  Not every Lesson Learned needs to be researched for normal operations.

Note that this involves Change Control at both the project level and at the organizational level.

As an example, engineers delivered documents to a customer without the necessary review and approval of the Chief Engineer.  The incident led to rework and incorrect customer expectations.

Tribal knowledge had established a channel that would have ensured proper review before release.  However, new employees did not know it, and management had nothing in writing that allowed them to discipline experienced employees who knew better.

Engineering stepped in where corporate management had left a gap.  They instituted processes for document review and approval and for an engineering communications manager to coordinate release of documents to clients.

Thus, an incident led to a Lesson Learned.  The Lesson Learned led to policy and procedural changes.  The new practice became part of the formal procedures and did not get lost in a database that ever researched.

Copyright 2013, Richard Wheeler -- Permission granted for non-profit or personal use with a link to this post.

IT Metrics and Productivity Institute (ITMPI) Premium membership gives members free access to 400 PDU-accredited webinar recordings and waives the PDU processing fees. The library is growing at about 100 webinars per year. Check it out: http://mbsy.co/dPHm?s=e

Agile, Waterfall, and PMI Project Differences

I've been asking about the differences between Agile projects and traditional project management.  Many explanations err by answering the question only from a software or Information Systems perspective.  While Agile primarily appears in the software industry, the different approaches appear in many industries and product areas.

Since the Project Management Institute (PMI) offers both Project Management Professional (PMP)^® and PMI Agile Certified Practitioner (PMI-ACP)^® certifications, it would seem that Agile contrasts against traditional project management. 

However, it would be more instructive to contrast the Agile approach against the "traditional waterfall approach" of Systems Engineering.  (Refer to the International Counsel on Systems Engineering (INCOSE) for details.)

Agile uses a highly iterative approach that works better when requirements are vague and must be defined over the course of the project.  It is more appropriate for, as an example, the next set of security updates to Windows or the next year's model of the Ford Mustang.

The waterfall approach assumes progressive or phased elaboration of a fixed set of requirements that can be defined, validated, and turned into a design architecture or solution, from top to bottom.

However, Agile methods can still be used for portions of the system, particularly peripheral functions of the software. It is more appropriate for, as an example, the core of MS Project 2015 or a new hybrid squirrel-electric vehicle.

 

Copyright 2013, Richard Wheeler -- Permission granted for non-profit or personal use with a link to this post.

IT Metrics and Productivity Institute (ITMPI) Premium membership gives members free access to 400 PDU-accredited webinar recordings and waives the PDU processing fees. The library is growing at about 100 webinars per year. Check it out: http://mbsy.co/dPHm?s=e

What to Call Risk and Opportunity Management

Many writings lump risk management and opportunity management together under the label, Risk Management.  Risks and opportunities are left-pointing and right-pointing rays on the same line.

Many equate risk with probability, so they drop opportunity from the label. They think of risk as an abbreviation for risk and opportunity. Others worry, then, that opportunity will be forgotten -- as it usually is!

When one speaks of risk [and opportunity], one speaks of the probability that something will happen. That is,

Risk = Probability x Impact, where Impact is a loss

and

Opportunity = Probability x Impact, where Impact is a gain

If risks and opportunities are rays pointing left and right, then opportunities are negative risks. If you deal with them in the same matrix, pay extra attention to your negative signs.

Risk and opportunity management can result in influencing the probability, influencing the impact, or other strategies such as accepting a potential loss or waiting to deal with situations when and if they become an issues.

(Remember that a situation is a risk if the probability lies between zero and one.  A situation is an issue if the probability is one.)

Uncertainty Management

Could we simply call it Uncertainty Management?  Uncertainty would only deal with influencing the probability that something will occur. The face-value of the term fails to imply the other strategies for dealing with risks or opportunities. The name of this knowledge area should reflect the highest-level concepts, not a component concept.

Opportunities and Threats

Another pairing of terms comes from SWOT analysis - Strengths, Weaknesses, Opportunities, and Threats. SWOT analysis is one technique for identifying risks and opportunities.

Opportunities and threats, as a pair, emphasizes the influences or situations that affect or can be affected by a person or project. (In fact, threat implies that the risk event comes from outside, whereas risks can be either internal or external.)  SWOT analysis emphasizes identification of risks. It makes up only a fraction of the whole set of risk and opportunity management processes.

A Common Risk:  Failing to Deal with Opportunities

Many people forget to manage opportunities with the same vigor that they apply to managing risks.  Exploiting opportunities can mitigate the potential impact of risks. The reasoning goes, Risk A may set us back a week, but Opportunity B may save us a week.

PMs have other reasons to exploit opportunities.   Exploited opportunities cut costs, relieve schedule pressure, and improve quality. In short, they maximize profit.

Failure to exploit opportunities wastes resources, causes product lines to stagnate, erodes market share, and results in lost jobs (perhaps your job!) when the company withers.

The failure to exploit opportunities is itself a fundamental risk.

Therefore, referring to the practice as Risk and Opportunity Management calls attention to the oft-forgotten second half of the discipline. 

Remember that semantics is about communicating, not about winning arguments.  If somebody refers to risk management, you know what they mean.  Adjust.

Copyright 2011, 2013, Richard Wheeler -- Permission granted for non-profit or personal use with a link to this post.

IT Metrics and Productivity Institute (ITMPI) Premium membership gives members free access to 400 PDU-accredited webinar recordings and waives the PDU processing fees. The library is growing at about 100 webinars per year. Check it out: http://mbsy.co/dPHm?s=e

How to Memorize PMP Formulas

Four Keys to Memorizing Anything

Memorization is like eating my biscuits. You use a knife and a cutting board to cut them into smaller pieces. Then you bite them into even smaller pieces with your incisor before chewing and chewing with your molars, sometimes on the right side of your mouth, then on the left side of your mouth.

Memorizing a formula, you use a pen and paper to break it into parts. Then you repeatedly work on the pieces. Sometimes you write them and sometimes you say them out loud so you involve more than one sense. Unlike my biscuits, you put the pieces back together in medium-sized pieces and chew on them for a while before putting the whole formula together and chewing on it.

The keys so far are

• Smaller pieces
• Repetition
• Multiple senses
• Reassembly

The Fifth Key to Memorization

The remaining key is (drum roll, please!)

• Analysis

If you can understand a formula, you can recreate it without memorizing as much of it.

Example:  Point of Total Assumption in a Cost Reimbursable Contract

• PTA = ((Ceiling Price - Target Price)/Buyer's Share)) + Target Cost

(I have limited the scope of this post to memorizing the formula, so please don't expect an explanation of Cost Reimbursable Contracts.)

The first step in analysis is to restate the formula in a fashion more visually decipherable.

• PTA = Target Cost  +  (Ceiling Price - Target Price) / (Buyer's Share)

Notice that I turned the formula around.  I like to write formulas the way you would see it graphed: with the biggest portion first, at the bottom. Look at the inconsistent way most people present the Cost Estimating formulas, and taking this liberty will make even more sense.

The contract is Cost Reimbursable, so the first part of the PTA is what we hope the cost will be, the Target Cost.

• PTA = Target Cost + some ugly fraction

The two price points above the Target Cost are the Ceiling Price and the Target Price. The Ceiling is higher, so it goes first:

• (Ceiling Price - Target Price)/something

Something is the Buyer's Share.  Sorry, you'll just have to memorize that.

This is the point where you take total assumption of your own learning and put the formula back together. Remember, the keys to memorizing are

• Smaller pieces
• Repetition
• Multiple senses
• Reassembly
• Analysis

Differences between Risks and Issues in Projects, Part 1

Differences between Risks and Issues in Projects, Part 1

Issues

Updated 1 June 2014

People define issue in many ways, but in project management, issue has a special meaning.

In everyday English, one synonym for issue is topic. An issue is a situation that merits discussion. For example, the issue, what caused the last ice age or is man's contribution to climate change significant compared to factors such as volcanic ash and the variability of our star.

Everyday issues include past, present, and future situations. Discussions about issues may or may not lead to actions. Often, when we say that something is an issue, we imply that people disagree about it.

In project management, an issue is a situation that merits consideration because it affects the project. For example, the vendor left our parts to rust on the dock and will not ship them until they get paid, but our policy prohibits paying for the shipment until we receive and inspect it.

If the issue is significant, the project team will study actions that would reduce or remedy the situation effects on the project. This leads to change requests.

Part 2 (click here) focuses on the definition of risk and explains a side of risk that most PMP prep materials overlook.

Copyright 2013, 2014 Richard M. Wheeler

Links to Management Resources

General Management Resources

• World Health Organization - Leadership and management topics
• Defense Acquisition University - Search engine for DAU resources
• Department of Energy - Directives, delegations, and requirements
• EverySpec - Collection of free US government (NATO, too) specs, standards, handbooks

Process Asset Samples and Templates

• Project Management Docs - PMBOK based project management templates
• Brad Egeland - Sample PM plans & templates, with links to related articles

Project Management Newsletters

• The Program Manager's Paper - Articles and links to articles useful to project managers

Project Management Resources

• Lessons Learned.info - Lessons learned (LL) in the context of project management (PM)
• Certified Enterprise Risk Manager® Academy - Risk-based problem solving & decision making, enterprise risk management: resources, training, certification, newsletter
• Herding Cats - Informative blog entry on uncertainty, risk, and risk management

Project Management Tools

• PM Tools Review - Project management & PM-related tools and services

PM Social Media and Online Study Groups

• Google Plus - Project Management, PMI, PMP Certification - Oliver Lehmann's outstanding Google+ group for PMP test prep, Agile, PM news recommended articles, almost everything PM
• PM Lessons Learned - Conference calls for PMP exam study, job hunting, and best practices every Tuesday plus the first through third Thursdays, 9 PM New York time; Archives of presentations and also a discussion capability are available at http://groups.yahoo.com/group/pmlessonslearned/

Technical References

• Department of Energy  - References, regulations, and requirements
• University of Maryland Space Systems Laboratory Spacecraft Design Reference Library
• EverySpec.com - Government and military standards, specifications, handbooks, and documents

PM Blogs

• The Southern Project Manager - Harry Hall's practical project management insights and tips

PM Study and Free Resources

• PM Study - Free Simulated Practice Test, Sample Guides and Podcasts, Work Experience Hour Calculation Tool
• PM Success - 400 Questions of the Day
• Head First Labs - Free PMP Practice Exam
• Simplilearn - Articles and instructional videos

Agile Study and Free Resources

• ScrumStudy - Free learning resources (including the ScrumStudy BOK) - Hat tip to Kylie Wilson in the Comments.

This is a work in progress. Add links to your favorites in the comments, below, and I'll add them.

Understanding the Rule of Seven

Context: Discussion of the Rule of Seven in statistical process control 

Problem: In some industries, one cannot wait for repeatable errors as defects and errors lead to loss of life. I was told that, in pharmaceuticals, a certain % of death is acceptable and almost expected. The waiting process or period of time before halting tests or evaluations is where I am stuck.

First, let's use the terms specified value and control limit rather than errors or defects.

 

Also, we would normally discuss this topic in terms of parameters that have numeric values such as temperature, weight, and speed. In this conversation, we want to deal with measurable characteristics long before they result in catastrophic failures.

Rule 1. Out-of-bound conditions

If you have just one value outside the control limits, such as a severe side effect from a drug, you stop the process and figure out what went wrong. 

Rule 2. Calibrating the results

The Rule of Seven (or Run of Seven) does not apply to parameters that go outside the control limits. The Run of Seven applies when seven consecutive, acceptable values lie on the same side of the specified value. Such a situation indicates that the average has deviated from the desired value and you need to recalibrate the process so that the average is close to the specified value.

Illustrating with a made-up scenario

Suppose the scientists at Schpooky Pharmaceuticals want to test an inoculation against the HG (Heebie Geebie) virus. In order to train the immune system to fight off a full invasion of Heebie Geebies when somebody sneezes on us, the inoculation has to cause a fever of at least 0.5 degree F. They calibrate the variables in making the vaccine and in the dosage to cause a 1.0 degree F fever, or a temperature of 99.6 degrees F.  In this test, they set an upper control limit of 3.0 degrees, or a temperature of 101.6 degrees F.

 

Specifications:

• T = 99.6 degrees F, average
• 99.1 degrees F < T < 101.6 degrees F

Using the first rule, just one person develops a temperature of 103.0 degrees F. We stop the tests to see what's gone wrong because 103.0 > 101.6, the upper control limit.

 

Using the second rule, if we have seven consecutive people develop fevers between 99.6 and 101.6, we stop the tests to see what's gone wrong. These temperatures are all acceptable, but they are all greater than the desired value.

 

The Run of Seven indicates a special cause -- that is, one or more variables in the process need to be controlled. Maybe the dose is too large and needs to be reduced. Perhaps the HG virus needs to be baked five minutes longer. So we make the adjustments and then resume the trial.

 

These rules and others like them serve to stop a process long before it reaches catastrophic failure such as the death of a patient.

But catastrophic failures do happen

You might wonder, What about the catastrophic failures? They do happen! What about the one in 10,000 who dies? How can that be acceptable?

 

This takes us to other techniques such as Decision Tree analysis (p. 299 of the Project Management Institutes Project Management Body of Knowledge (PMBOK) Guide, 4th edition).

 

Suppose withholding the vaccine results in 1,000 deaths per 10,000, but giving the vaccine causes one death in 10,000. If you distribute the vaccine to 10,000, you save 999 lives.

 

Unfortunately, many drug companies withhold such drugs because that one in 10,000 will sue them, and the juries will severely punish the companies.

 

This issue, tort reform, is one of the dividing lines between the political parties in the US. A project manager needs to use various decision-making methods and maintain awareness of a wide range of environmental factors.

Life Cycle Costing for Projects

Defining Life Cycle Costing

Life cycle costing (LCC) looks at the cost of the whole life of the product, not just the cost of the project. A product has two major cost phases, the project phase that designs and produces the product, and the O&M phase where the owner operates, maintains, and decommissions the product.

(A lot of Project Managers (PMs) forget decommissioning. As an extreme example, consider how much it will cost to maintain and protect a nuclear waste site for the next 500,000 years.)

The design philosophy is part of the project scope.  The customer may want a cheap, disposable product, so the design team would not put much effort into designing for low maintenance, low manning, and long lifespan.

On the other hand, the customer may need the product to last a long time.  Operations costs can include:

• building more units
• maintaining equipment
• training users
• expanding, upgrading, or re-purposing the product
• providing consumables
• procuring replacement and spare parts
• transporting, installing, or disposing of waste

Operations can far outweigh the initial cost.

The scope statement, the Statement of Work, the nature of the product, industry standards or government regulations, and the user needs can guide decisions about what aspects, if any, of life cycle costing to include in project planning.

What LCC Means to the Project

Considering operations and maintenance costs requires including, as part of the scope, performing the project in such a way as to keep O&M costs down for the customer.

For example, easy access to a car's timing belt decreases the amount of labor the owner has to pay to have it replaced, and using a steel widget instead of an iron one results in fewer failures due to corrosion.  Such steps will increase the cost of the project, but they may decrease the customer's total cost of ownership.

Considering operations and maintenance costs also requires estimating the cost of the entire product life cycle.

A point exists where spending more on reducing O&M costs would not cut total cost of ownership.  For example, making windshields out of the material they use in Soyuz windows might mean never having to replace cracked glass after a bird hit, but it would cost more than the rest of the car.

For this reason, the project will include a trade study that estimates the total of both the project cost and all the costs incurred by the customer after product delivery.  As its goal, the study will recommend ways to minimize the total cost.Expand this comment »

What LCC Means to the Project Manager

The PM should consider the following steps to ensure project success:

• Make sure the customer considers cost of ownership and agrees to LCC goals.
• Ensure that project scope and project requirements clarify LCC goals.
• During project planning, account for the effects of those requirements on the project.
• Oversee a trade study to determine the best compromise between project cost and O&M costs before project planning is finalized.
• Make sure the customer understands cost tradeoffs between a cheap project and a project that produces a product with characteristics such as longer life, less expensive maintenance, and greater safety.
• Get approval of the LCC strategy from the customer and authorization to follow that strategy from the project's sponsor or management.

Please let me know in the comments if you have any corrections or additions.