Cloud Computing Risks

I have posted an article about yesterday’s “Gmail Outage & Cloud Computing” on my new blog.  You certainly need to consider outages as an identified risk for cloud computing and develop appropriate service level agreements (SLAs).

Technorati Tags: it pm,information technology,project management,gmail,google,outage,cloud computing,client-server,risks,mitigations

Tough Client Questions

It is a certainty that clients have become more picky about who they will hire.  It is also pretty evident that many in IT are now using this opportunity to turn to going it on their own.

That’s why I think Chip Camden’s article on TechRepublic about “Answering client questions about perceived risks and benefits” is a good one to read if you are contracting or thinking about it.

For example, if you are just starting out, you may be the only one in your “firm”.  So, how do you answer the question, “How many people are in your firm?”  Remember, there’s an upside as well as a downside to being small.  Think communication.  Think reliability.  Those are the risks that the client wants to mitigate.

That’s one of the questions.  Chip asks 6 others.  A recommended read.

Technorati Tags: it,information technology,consulting,clients,risks,benefits,communication

Ambiguous Scope

If you don’t know where you are going, then you won’t know when you arrive.  It really is a simple concept, but it seems to go over the heads of many executives.  Unfortunately, it seems to go over the heads of some IT folks as well.  When that executive wants something and wants it now, it is hard to push back sometimes.  However, “something” is not a scope statement!

If I am dying of thirst, and I ask for a drink, then should I be dissatisfied when I get a cup of coffee instead of water?  Now, I love a good cup of coffee as much as the next coffee addict, but I also know it isn’t going to cure my thirst.  No, I should have been more specific.  The person giving me the drink should’ve asked questions.  Both failed to ask questions, and the task was not a success.

What makes a successful project?  Isn’t it one that delivers the goods?  If you don’t know what the goods are, how do you know when you succeed?  You don’t.  How do you know when you fail?  When you have angry people making demands of you, which is almost a surety if you don’t live up to their expectations.  That is almost a surety when the scope is not properly defined.

Ask the questions on any project:

1. What is success?
2. How do you measure success?
3. When are you done?
4. How do you measure done?
5. What is the minimum required?
6. What is the maximum timeframe?
7. Can the minimum required reasonably be planned, constructed, tested, reworked and retested in the maximum timeframe?
8. Will subject matter experts (SMEs) be available throughout the timeframe, or will you have to rely upon less experienced workers?a. Who is indispensible to the project’s success?  When will they most be needed and can you be guaranteed their availability during critical times?

   b. If less experienced people will be used, then is it reasonable that you can still do the minimum within the maximum timeframe?

9. Are there any stakeholders who do not buy-in on the changes?
10. Do you have executive support (real, not lip service)?

If any of the above are a concern, and if you cannot come up with a reasonable workaround or mitigation action for it, then it needs to be identified as a risk factor.  The likelihood of the risk occurring must be widely published.  The project sponsor must be engaged with the risk.

Remember that an unmeasurable business goal is no goal at all.  Don’t start out with a hardware or software change as the goal.  No, hardware and software changes may be functional requirements that support the business goal, but they are not in themselves the goal(s).  “Change web interface to make customers happy” is not realistic or measurable.  “Increase online sales by 5% by providing customers online discount codes” is a lot better.  Now you have a business goal, you can start asking the question of where do the discount codes come from, how much the discounts are for and how and when they will be input into the system.

If you started with the interface, then the goal becomes short-sighted.  You may not involve anyone in sales.  You likely would not realize that you needed their involvement until late in the project.  They may be only vaguely aware of your project, and they will likely have made assumptions about how it would work.  The end result would likely be that no customer would receive any discount codes, so sales would remain flat in spite of any work being done.

Even worse, if the project sponsor cannot tell you definitively when a project is done and a success, then your project will have constantly shifting requirements, priorities and timelines.  Force the measurements upfront.  This will force any disagreements among stakeholders to be uncovered at the beginning and not at the end.  This will differentiate between a success or a failure in objective terms.

Measurable goals help to define original scope.  One requirements are mapped to the goals, and as long as the requirements themselves are measurable, then original scope is established.  If there is no way to measure it, then the enduser/sponsor will want additional items put in without effective controls.

Technorati Tags: it pm,pm,project management,requirements gathering,scope,risks,project control,control,success,failure,avoiding troubled projects,pm basics,metrics,measurements,when are you done

Defensive Programming

Remember when you learned how to drive, and you had to take a course called “defensive driving”?  You learned to anticipate problems on the road instead of racing down the road assuming nothing would ever go wrong.  By driving in a manner that would put you in the best position possible should something go wrong, you often avoided anything going wrong at all.

Software developers tend to be an optimistic bunch.  Write code for that?  No problem!  Want it in a week?  No problem!  Somehow, they tend to underestimate the power of a computer to do only exactly what it is told to do, whether by their own code, someone else’s they have to interface with or the compiler.

Agile development encourages people to do their test cases up-front.  I am in complete agreement with that concept.

There are problems with that, as there are with anything in life.  In “Developers Can’t Test for Toffee!”, Kelly Waters asks, “Why is it that developers can’t test?”  Waters pretty much states it is the “can’t see the forest for the trees” syndrome.  Developers can only test for issues they think of.  They are down in the bowels of the code, so naturally testers can think of scenarios the developers have not.

Waters makes a pretty good case, I think.  However, my experience is that most developers aren’t trained to think about what goes wrong.  I remember more than one post-mortem where I would ask, “Why wasn’t this accounted for?” and the answer very often was “I never thought that [condition] would occur.”

I guess I was fortunate in that I had a professor who insisted that code ran and produced the expected result.  “Code for the error conditions first,” he used to say.  “Think about what will happen, because it eventually will, when you get in some bad data.  Don’t assume users will input valid data.”

I began to call this concept “defensive programming”.  Anticipate the problems before the best case scenario is even written.

Technorati Tags: pm,it project management,software development,programming,coding,bugs,risks,risk management,defensive driving,defensive programming,agile,test cases,developers,testers,kelly waters