Praise for the Taxonomy Based Questionnaire OR Avert Disaster by Asking the Right Questions

Happy New Year Dear Reader!

I had a fabulous New Year as I attended my very first Mummer’s parade in Philadelphia!  What is a Mummer and what is the parade about – well, google it – and suffice to say it was one of the most trippy new years I’ve ever had.

Check the video – you’ll be glad you did – Just regular folks getting all dressed up for no good reason.

So lately I’ve been building out risk management in my organization, and as I was sizing up my risk log I unconsciously reached for my trusty Taxonomy Based Questionnaire, and a still small voice rose up in me that said quietly ‘other PMs should know.’  And suddenly,  I was flooded with appreciation the likes of which you feel when you realize a pair of well made old boots has served you well over many years.

This questionnaire has become un-questionably ( :> ) my most valuable project management tool because it reminds me of everything that could possibly go wrong on a project, and gives me the language to use to address it.

The secret's out! The Taxonomy Based Questionnaire can save your behind!

A taxonomy is a ‘classification into ordered categories.’  The Software Engineering institute at Carnegie Mellon (you know, the CMMI folks) created the Taxonomy of Operational Risks back in 1993. The Taxonomy in and of itself is good enough to jog a PMs memory of hindsight realizations you rather not have in hindsight anymore.

SEI Risk Taxonomy

But the best part is the questionnaire based on the taxonomy, hidden in the back (skip to page B-3) of  the 1993 Taxonomy-Based Risk Identification publication.  1993!  Think of how many failed projects could have been saved by asking questions like…oh, I don’t know…

[144] Is the schedule realistic?

(Yes) (144.a) Is the estimation method based on historical data?

(Yes) (144.b) Has the method worked well in the past

or

[17] Does any of the design depend on unrealistic or optimistic assumptions?

or

[7] Are you able to understand the requirements as written?

(No) (7.a) Are the ambiguities being resolved satisfactorily?

(Yes) (7.b) There are no ambiguities or problems of interpretation

Seems simple enough, but asked early enough and loudly enough, these questions could prevent you from disaster!

So take a look, (skip to page B-3),  read through them, ask them, loudly and often.  Your project will be happy you did!

Right Here in River City: Cyber Attack in DC?

Welcome to DC

Welcome to DC

I’m off to a meeting but couldn’t resist a quick post about the fact that the commute from hell has descended onto DC because of ‘computer glitches’. My thoughts:

1. Terrorism planning should be a standard risk with a subsequent mitigation strategy identified and thoroughly documented in a contingency plan for any infrastructure related IT projects.

2. Said contingency plan must be battle tested.

3. The conspiracy theorist in me is now slightly freaked out by DC Metro Area transportation problems.

Good article on the subject below.

Reprint from WTOP.Com reporter JJ Green

WASHINGTON – Commuters in Montgomery County Wednesday woke up to what seemed like an unfortunate but benign breakdown in the traffic control system.

“In Maryland, Montgomery County, the computer that controls the traffic signal apparently has crashed,” said WTOP morning traffic reporter Lisa Baden.

She went on to report, “Your signals are not in rush hour (mode) and there is nothing Montgomery County can do to change that except ask for your patience.”

At the same time, the 106-mile regional subway system, which transports 750,000 people in the Washington Metropolitan area fell victim to a recurrent computer glitch. Riders couldn’t use their debit cards to pay for their trips. Many had to leave the stations and find other means to reach their destinations. For some, this was at least the third occurrence of this kind in the last month.

The two events were not connected or were no more than untimely breakdowns. Montgomery County officials say the traffic signals went down because of outdated equipment. WTOP’s Adam Tuss says, the Washington Metropolitan Area Transit Authority computers failed because of power outages.

“Metro also has a tough task trying to prevent any sort of cyber attack against its system. As you see, one glitch and the computer system goes out of whack,” says Tuss.

But were those faulty systems further damaged by outside forces?

On Aug. 14, 2003, at approximately 4:15 p.m. EDT, a massive widespread power outage occurred throughout parts of the Northeastern and Midwestern United States and Ontario, Canada. Roughly 45 million people in eight U.S. states and 10 million people in Ontario were left in the dark. It was the biggest blackout in history.

It was blamed on FirstEnergy Corp.’s failure to trim trees in part of its Ohio service area and an electronic flaw in General Electric Energy’s Unix-based XA/21 energy management system.

But quietly, intelligence officials discussed the possibility that the Chinese People’s Liberation Army gained access to a network that controlled electric power systems and brought down the grid.

A growing chorus of U.S. intelligence and cyber authorities are revisiting the possibility the Chinese may have been involved in 2003, and other cyber glitches in the U.S.

“Some day, somewhere, sometime, we’re going to have a massive cyber attack which will disrupt activities in this country. You can almost bet on it,” says Lee Hamilton, former vice chair of the 9-11 Commission.

“If you’re able to take down part of the electricity grid, pretty much everything fails,” says the former director of the Central Intelligence Agency James Woolsey.

“You don’t have water being pumped. You don’t have sewage being pumped. You don’t have deliveries to grocery stores. It’s pretty difficult to figure out what does work under those circumstances,” Woolsey says.

To put it into context, Woolsey says, “Imagine a world that is not pre-1970, pre-Internet, but imagine a world that is pre-1870, pre-electricity.”

First, the local and regional chaos would begin to set in, says John Bumgardner, research director of the independent, non-profit U.S. Cyber Consequences Unit.

“If you start having a day or two without power it’s an inconvenience. You starting getting into a week, you start getting into a major inconvenience. Everything starts to collapse after about a week.”

Then the bottom falls out, former Director of National Intelligence Mike McConnell says.

“Think about the consequences of no electrical power in the U.S.A. I would argue in a short period of time it would have devastating consequences for the globe – loss of confidence in the U.S. dollar.”

That’s the reason why Pete Earnest, director of the International Spy Museum, and his staff have launched a series of speakers’ events designed to educate the public about the vulnerability of the electrical system to hackers.

“This is one of the things we’re all living with, and what we depict here is the nature of the threat and we take the possibility that it could bring down portions if not the entire electrical grid,” says Earnest.

A critical piece of the effort at the Spy Museum is a video and graphic exhibit called “Weapons of Mass Disruption.”

“I think people need to be aware that cyber attacks are harder to understand because you can’t see them. It’s one thing to have people fly a plane into the building and cause deaths. But these cyber attacks are taking place every single day and in many cases we don’t know who is behind them,” says Earnest.

Making Theory Usable: A Risk Register for the Rest of Us OR A Few More Reasons for Project Failure

Ahhhh, the LIM Man oh man did I have a great time at the PMI Leadership Information Meeting (LIM). The LIM occurs every year just prior to the PMI Global Congress and it’s a gathering of all the PMI leadership from the branch on up. I went as a leader in the Washington, DC Chapter’s Outreach committee.  First of all, the congress was held at the fabulous, beautiful, glorious Gaylord Palms. I can’t say much for the rest of Orlando because I never saw it. Staying at the Palms with its 7 story high glass enclosed atrium complete with gator ponds (don’t feed the gators), 3 pools and as many or more bars, lounges and restaurants, and an indoor type venetian strollway, was quite enough for me. It was like being on a cruise on one of the massive ships, and the food was fabulous..really wow!  I should ask the Gaylord to pay me for this.

The Gaylord Palms (sigh)  - Didn't want to leave

The Gaylord Palms (sigh) - Didn't want to leave

And there is nothing I love more than meeting people as I’m a bit of a an extroverted geek.  Like.. my team really couldn’t understand that I would actually be happy meeting advanced PM practitioners and talking all hours into the night about project management.  They thought I was going to head for the beach after sessions.  Not.  To me there’s nothing better than reaching across a table and saying “Hey, I’m Michiko from the DC Chapter” and they go “Hi/Hello I’m Ahmed/Karesh/Bea/Lyssa/Judy from the Arabian Gulf/Mumbai/Arkansas/South Africa/Tampa Bay” chapter.  And I miraculously kept meeting the right people.  Like the woman from the Tampa Bay chapter who I just happen to sit next to who is running an awards program like I am (her’s is way cooler so I told her already I’m copying her), or the woman who is starting her consultancy just as I am or..and this is the focus of this blog…someone who I had admired who turned me on to even more fantastic research for me to read.

Cause I’m a Geek – yea, yea, yeah Poor John Estrella, we were just chatting after a session; standard where are you from stuff, I mention I have a blog, he mentions he’s got a book and then I stop and say ‘what is your name? again (because he had told me but ya know, in one ear out the other) and he goes John Estrella and I’m like John ESTRELLA – OMG I so knowyou!Isatthroughyourfinancialservicessigswebinar and yourbooksoundsfascinating and I’msogoingtogogetit and the poor guy. I guess I don’t look like a geek anymore. I look kind of normal now so there are no indicators that I will go off on overly excited tangents about fantastic datasets and their application to the practice, so I think I sort of scared him.

Really?  Quantitative Data on Project Risk Factors?? So COOL!

Really? Quantitative Data on Project Risk Factors?? So COOL!

Anyhow – went and bought the book – yes, downloaded it and read it during off hours at the conference. I have earned my geek wings so this should be no surprise to you.  And the great thing about his book is that he has real data to back up him theory of what he believes are the key reasons for software failure.  I know, so exciting!   Sure there’s lots of theory out there, but his is quantitative data.

Oh Goodie!  A Growing Data Set! For his PhD, John also conducted a fairly definitive review of the literature and theory, approaches, methods and models in project failure analysis.  I mean, its all there.  Remember that it’s a PhD dissertation so the reading is a bit dry for the average reader but if you want to understand all the theory in project failure analysis and how models interface and interact with each other, Identifying Software Project Risks in the Canadian Financial Services Sector is the book to read.

Good Book

Good Book

So that part was cool.  But what’s really great about John’s research is that through this work, he is confirming trends that exist across countries and adding to the body of data which indicates that across cultures, sectors and countries, when it comes to preventing software project failures there are indeed a set of top risk factors that appear again and again.

Why is this valuable?  Well, it suggests that you, IT PM, can start off with that theoretical basis of understanding built right into your project, from the beginning.

Manage for these risks and you have statistically increased your chances for success. And this isn’t just theory anymore kids, its based on hundreds of interviews of real IT PMs like you.   I know, I know – get to the data already. BTW – John calls these ‘Project Risk Factors’ but for ease of understanding, I’m going to call them ‘Reasons for Project Failure’.   Here ’tis:

Top 16 Reasons for Project Failure(Canadian)

  • Misunderstanding of the requirements
  • Failure to manage end user expectations
  • Unclear/misunderstood scope/objectives
  • Scope creep
  • Lack of dedicated, full time project resources
  • Lack of frozen requirements
  • Bad estimation
  • Not managing change properly
  • Lack of top management commitment to the project
  • No planning or inadequate planning
  • Lack of available skilled personnel
  • Lack of effective project management skills
  • Improper Definition of roles and responsibilities
  • Failure to identify all stakeholders
  • Changing Scope/objectives
  • Poor Risk Management
  • Now these are the top factors for Canada, particularly the financial services sector.  John provides a chart where, using this same elicitation technique, researchers in Hong Kong, Nigeria, Finland and the USA, had similar risk factors but slightly different rankings, indicating that there are more prevalent reasons for project failure depending on the context.

    But what about the top 6 reasons for Project Failure advocated by the UK NAO that you talked about last week Michiko?  I knew you were going to ask that. Here is how I see the relationship.  I’ve taken the NAO’s top reasons for project failure and correlated them to Johh Estrealla’s top reasons for project failure.  Here’s what I think it looks like:

    UK NAO Reasons for Project Failure

    Canadian Data Set Reasons for Project Failures

    intent

    Unclear/misunderstood scope/objectives

    sponsor

    Lack of top management commitment to the project

    design/definition

    Misunderstanding of the requirements

    design/definition

    Bad estimation

    design/definition

    No planning or inadequate planning

    communications

    Failure to manage end user expectations

    supplier/vendor

    Lack of dedicated, full time project resources

    supplier/vendor

    Lack of available skilled personnel

    supplier/vendor

    Improper Definition of roles and responsibilities

    project discipline

    Scope creep

    project discipline

    Lack of frozen requirements

    project discipline

    Not managing change properly

    project discipline

    Lack of effective project management skills

    project discipline

    Failure to identify all stakeholders

    project discipline

    Changing Scope/objectives

    project discipline

    Poor Risk Management


    Conclusions and a Free Gift Three conclusions here:

    A good many of these reasons for project failure are in the hands of project managers.    This means that good application of PM methods has a real measurable impact to the success of a project.

    Alignment of theory suggests truth. The NAO UK grouping incorporates the Canadian samples project failure reasons even while the Canadian sample is more explicit about project failure reasons.  But there is an alignment here that a researcher should explore in more depth.

    Commonality across cultures/context suggests truth. Studies in Canada, Finland, Nigeria, the UK, the USA are suggesting similar reasons for project failures.  This suggests that there are reasons that should be considered standard things to mitigate against during a software build.

    This blog is all about making this useable. So I have created a sample risk register with key questions sourced from this theory.  This is a tool you can download and use right away on your project.

    Your Free Gift >> The Making Theory Usable Theory Based Risk Register

    Next Steps for the Outstanding PM Ask the questions of yourself and your projects.  Rank the impact and probability and then take action by thinking about a mitigation strategy for these risks.

    Identifying Project Risks in 4 easy steps; OR Why Complaining is your best friend

    Mitigating for risk can be your best friend. I mean it, and I’m not saying this to sound all geeky smart. I have been thoroughly saved over and over because of risk management. Here’s the problem as I see it right now in the PM environment, and as I’ve witnessed with many PMs.

    PMs are scared of risk management.

    They are scared because they don’t really know HOW to identify risks and yet they have this sinking feeling that they probably should. After all, there’s a whole chapter devoted to risk analysis is the PMBOK so we should all, as PMs, sort out and identify and mitigate for risks as a key component to our projects…right…RIGHT???????

    Ok –I’ll stop beating you up. I already did that with my staff today. So I’ll be nice on this one.

    Again, the PMBOK tells you that you should mitigate for risk but doesn’t really tell you how to find a risk. So I’m going to give you the most tried and true method that I know, and its easy and fun to do. Follow me.

    Step 1: Complain about your project

    I’m completely serious here. Start bitchen – write it down, or talk to a friend or wipe board it. Whatever, just start complaining. Because the key to every project risk that you need to manage is buried somewhere in all the things that are driving you completely nuts about your project.

    Here’s a familiar rant:

    “Man..this project SUCKS! The previous PM left it in a complete shambles, totally wasted the client’s money and now I have to come in try to piece it together. I have NO idea what the requirements are because they are stuck in some 20 page long excel sheet that has no correlation to anything we’ve built or tested. I can’t tell what’s going on. And my boss has totally had it out with the client CEO – they aren’t talking. This is completely impossible.”

    That’s a fairly good rant. So…let’s pull out the problems.

    Step 2: Pull out the problem

    If you’ve written down your rant, that’s gravy. Let’s assume that you did. Or a very good friend did it for you as you stomped around the conference room. What you are looking for is the problem statement within the rant. Let’s look at some examples:

    Issue : “The previous PM left it in a complete shambles”
    Pull out the problem: Poor Project management Practice were employed in the past

    Issue: “totally wasted the clients money”
    Pull out the problem: The client may not have enough money to continue the project

     

    Issue: “I have to come in try to piece it together. “
    Pull out the problem: As a new PM on a project where time and money were wasted, I won’t have any credibility.

    Issue: “I have NO idea what the requirements are”
    Pull out the problem: Unknown requirements exist

    Issue: “no correlation to anything we’ve built or tested”
    Pull out the Problem: What was built may or may not address the requirements


    Step 3: Figure out how your project will fail

    This next step is where you pull it together. By now you’ve identified what’s wrong with the project (step 1), you’ve identified the problem (step 2). Step 3 is about asking yourself – how will this thing I’ve identified make my project fail? This is your risk.

    Your key phase is:

    Because of __[blank]______________ my project may fail.

    Let’s go through some examples:

    Issue : “The previous PM left it in a complete shambles”
    Pull out the problem: Poor Project management Practice were employed in the past
    Risk: Because of previous poor project management practices, my project may fail.

    Issue: “totally wasted the clients money”
    Pull out the problem: The client may not have enough money to continue the project
    Risk: Because budget resources may be depleted, my project may fail.

     

    Issue: “I have to come in try to piece it together. “
    Pull out the problem: As a new PM on a project where time and money were wasted, I won’t have any credibility.
    Risk: Because client confidence is diminished, my project may fail.

    Issue: . “I have NO idea what the requirements are”
    Pull out the problem: Unknown requirements Exist
    Risk: Because previously unknown requirements may surface my project may fail.

    Issue: “no correlation to anything we’ve built or tested”
    Pull out the Problem: What was built may or may not address the requirements
    Risk: Because previously unknown requirements may surface my project may fail.

    Step 4: Figure out what to do about it

    I really love the Army…or more accurately ..Army folks. They just know how to say everything right. In a report I just read, one commander described how building roads was key to reducing insurgency in theater because the more roads, the more people and infrastructure could travel to, and positively influence populations who otherwise would might have become terrorists. I’m digressing a bit just to get to this awesome quote:

    “Where the road ends, the insurgency begins”

    As PMs, our job is to build the road, to anticipate and warn and build so that people on our projects can confidently walk on the road we’ve built.

    Figuring out what to do, otherwise known as Plan B, otherwise known as Risk Mitigation builds the road, anticipates what’s going to happen and plans for it. Better, it makes you look like solid gold. You’ll gain credibility in the eyes of your client the minute you bring to them all the issues you’ve identified in steps 1,2, and 3 and invite them to figure out what to do about it. To sound fancy you can invite them to a “Risk Mitigation” session.

    Risk Mitigation is a big corporate-sounding word that is really about ‘what are we going to do about this?’ It’s your Plan B.

    Let’s go through the examples:

    Issue : “The previous PM left it in a complete shambles”
    Pull out the problem: Poor Project management Practice were employed in the past.
    Risk: Because of previous poor project management practices, my project may fail.
    What to do about it (Risk Mitigation): The project will follow PMBOK best practices. The client will be able to escalate problems with the project manager directly to the Program Manager.

    Issue: “totally wasted the clients money”
    Pull out the problem: The client may not have enough money to continue the project
    How can my project Fail?: Because budget resources may be depleted, my project may fail.
    What to do about it (Risk Mitigation): A budget report will be delivered on a weekly basis that compares work completed to dollars spent. (Or you could say something like ‘EVM will be employed’) . The client and the PM will discuss progress on a weekly basis on budgetary constraints.

    Issue: “I have to come in try to piece it together. “
    Pull out the problem: As a new PM on a project where time and money were wasted, I won’t have any credibility.
    How can my project Fail?: Because client confidence is diminished, my project may fail.
    What to do about it (Risk Mitigation): The client will periodically provide an anonymous assessment of the PMs work directly to the Program Manager. ( I know – a little big brother – you’ll work with the client to come up with something better)

    Issue: . “I have NO idea what the requirements are”
    Pull out the problem: Unknown requirements Exist
    How can my project Fail?: Because previously unknown requirements may surface my project may fail.
    What to do about it (Risk Mitigation): All new requirements must be managed through the change control process and entered in the change control log. The client will decide on prioritization of these requirements. The development team will provide estimates to aid in the prioritization decision.

    Issue: “no correlation to anything we’ve built or tested”
    Pull out the Problem: What was built may or may not address the requirements
    How can my project Fail?: Because previously unknown requirements may surface my project may fail.
    What to do about it (Risk Mitigation): The PM will do a thorough review of the requirements and share this with the client on…. [Date].

    In one of my next blogs, I’ll give you real life examples of project risk registers that completely saved me from total doom on many a project. In the mean time, practice makes perfect. And you get to start this practice by complaining! What could be better than that?

    Let me know what you come up with!