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

Should It Be Hard?

From the “Don’t Make It Hard” files: The right way and the wrong way to make things hard.

We should clarify the phrase “don’t make it hard”.  Some things are meant to be hard.  It is a tool.  It is used  to better our own (personal or corporate) positions.  For example, you want it to be hard for your competitor.  You want to create what Seth Godin calls “The Dip” for those who would otherwise take your market share.  You want it to be hard enough for candidates who apply for a job that the bottom feeders are weeded out.

May I use an analogy?  Cement is a good all purpose agent to build structures.  Cement, or concrete if you prefer, makes excellent sidewalks and driveways under the proper conditions (I’ll spare the long story about my own driveway).  However, it can also make a horrendous mess if poured incorrectly.  It also isn’t good for using a chisel on in order to chisel out a statue, similar to marble.

Both cement and marble are hard.  However, they have different purposes.

There is a small company looking for staff, but they have had a vacant position for some time now.  That may be hard to believe in this economy.  It isn’t because of cost necessarily.  They are just looking for a good quality fit.

Are they being too picky?  Maybe.  Maybe not.  Time will tell.  Most likely, they will find that quality person and fill the spot.

Barriers to entrance is one way that making it hard can be good.  You want the best for your investment, after all.

Of course, that type of barrier depends upon knowing what you want.  One way you can make things hard is to have an “Ambiguous Scope”.  A common cause of an ambiguous scope is the client doesn’t know what they want.

Contrast the example of the small company above with another company looking for a contractor to fill a need for a short-term task.  Initially, it seems they know what they want.  The funny part is that it should be a rather straight-forward little project.  Emotions and politics have clouded their judgment.  They will probably pay too much for too little because what they are asking for doesn’t match their real concerns.  As you dig into it, you begin to realize that the contract may not be in your best interest to pursue.  Red flags are being thrown, flares are going off, and your gut tells you it’s not a good idea.

In other words, you begin to realize that they are making it hard – on themselves.  Without going into specifics, they cannot see the forest for the trees, so they are lost in the forest even though there is a pathway in sight.

There is a time to make it hard – for your competitor, for prospective long-term relationships (yes, there are hopefully barriers to entry for marriage as well as employment) and even for criminals.  However, when you make it hard for yourself, those in a long-term relationship with you (which presumably includes employers) or customers, then you are adding unneeded stress to everyone around you and potentially harming those relationships.

Technorati Tags: it pm,information technology,project management,making things hard,obstacles,barriers to entry,contracting,employment,interviews

“Hands On” Project Management

We’ve all seen the ads: “Wanted: Hands-on Project Manager”.  I’ve even seen one that read something to the effect of, “This is not just an admin position.”  And, let’s face facts, shall we?  Some PM positions are basically bureaucratic paper-pusher positions.  So, the sentiment is understandable.  I also believe that most PMs are not like that.

That being the case, why does an ad like the above scream, “Run for your life!  Danger, Will Robinson!  Danger!”?

I truly believe it comes back to different interpretations of “hands on”.  Like I discussed in the post “Why the Role of Project Manager is Different”, “I consider myself pretty ‘hands on’ because I run the project.  I question people’s timesheets.  I ask them why things are taking so long.  I interfere and get them help if needed.  I do EVM calculations whether you ask for them or not (because it helps me do my job).  Do you want me to code?  Then you are not looking for a PM.”

Ron Ponce over at Project Manager Planet puts it in perspective in his 29 May 2009 post “’Just Tell Me What to Do!’ – The Case for Active Project Management”.   He rightly points out that you can publish a Gantt chart of tasks that is a thing of beauty, but developers still might not know what to work on next.  He writes:

“I just want to be told what to do and when,” says Kevin Kinsella, IT Regional Manger based in San Francisco. “The best project managers that I have worked with have been able to keep the project on track by telling me and the team when things were due or what may need my immediate attention.”

Kevin is not alone in his view about what distinguishes a successful project manager from the rest. Successful project managers are able to provide their teams and management with a proactive and hands-on style of managing and communicating that ensures their overall projects will succeed. What I call active project management or APM.

APM as a consistent style is elusive for many project managers because they generally don’t see themselves as passive; even though their team does. In many cases, that disconnect between the project manager and the team is not realized until after the project is completed―and then it’s too late.

That, to me, is being “hands on”.  PMs who code are not “hands on”.  They are distracted.  Unless the project is small, the distraction may cost the project.

One of the leadership principles that I learned early on in the Army that doing grunt work eventually distracts from what you really are getting paid to do: Lead others to accomplish the mission.  Being in charge (I mean, really in charge, not just be handed a title) means you have to be fully engaged on multiple items at the same time.  This was before “multitasking” became a mainstream word.  You are already multitasking, so why take on additional unneeded distractions?

Notice, I said “unneeded”.  In order to meet the deadline, you may have to get down with everyone else and shovel some dirt.  You may have to sacrifice some in your oversight in order to get the main mission accomplished.  However, you do so at the risk of not being in position to observe other activities going on.  Those other activities may or may not come back to bite you.

Those are the trade-offs.  Knowing what trade-offs to make is part of good management skills.  You weigh the risks.  The more project tasks you take on, the fewer management tasks you are doing.

Technorati Tags: it pm,project management,information technology,hands on project manager,active project management,leadership,roles and responsibilities,risk management

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

Don’t Make It Hard!

It never ceases to amaze me just how complicated people can make things.  Human beings have a remarkable capacity to overcomplicate things.

Let’s take project management.  You plan it.  You do it.  You evaluate how you did.  So, what’s the problem?  Usually, the problem is that people are involved.  You not only have to manage risks and issues, but you have to be aware of the human potential for creating risks and issues independently.

A co-worker manager once remarked that managing software developers is like herding cats.  I cannot take offense at that, as I know I resemble that remark.  Cats are independent and unpredictable.  People are too.  Software engineers are sometimes even more-so.  In an effort to work out all contingencies and to be all things to all people, software developers will sometimes code in things that are too complex for what is needed.

A good PM needs to be mindful of these things and be able to cut through the noise.  Simplify, simplify, simplify.  Even doing a WBS is an exercise in breaking the complex down into simpler more manageable components.

That doesn’t mean that things don’t just plain go wrong.  In fact, I’ve noticed that things go wrong every day.  On a good day, perhaps only one thing will go wrong.

However, how your team reacts to these events can make things better or can make things a lot worse.  This is where the PM must put on their motivational hat and get the responsible party or entire team to focus.

I had a conversation earlier this week that bowled me over.  One of the people was making a big deal out of implementation.  All I could think was, “Why is he making this so hard?” and “Why is he making a big deal about this?”

Things go wrong.  We all know that things can and do go wrong during implementation.  What causes things to go wrong at implementation?  I mean big things; I mean things that go terribly wrong.

1. Someone wasn’t doing their job.  Unfortunately, this is usually the cause.  Someone overlooked something, had a hidden agenda or otherwise had a “human moment”.  We’ve all done it (well, except hopefully the hidden agenda part).  That “someone” may be a developer, a tester, a manager or even the customer.  Yes, the customer has a job too, and it is your job as the PM to gently remind them of that if they forget, just as you would any other member of the team (including yourself!).
2. It just plain wasn’t meant to work right, at least the first time.  It might be an act of God, nature or just plain chance.

These are both tricky.  In some environments, even the latter category can be a political nightmare.

When someone fell down on the job or even if they fell asleep at the wheel entirely, it is helpful to remind yourself of all the good the person has done throughout the project.  Go over this list at least 3 times before you have a chat with them.  If you have difficulty thinking of anything substantial they have done right during the project, at least one of you definitely has a more severe problem.

Some things just are going to happen.  Some things may be more predictable than others, and it is prudent to ask if reasonable steps were taken to mitigate such a situation.  It is unlikely you can predict a lightening strike during a rollout.  However, if all that occurred was that the power grid was knocked out, then a reasonable effort would have been to ensure servers are on backup power.  The question remaining would be if a remote PC console would be on a UPS under reasonable circumstances.

One thing about a rollout is that it is the culmination of effort up to that point.  The implementation phase is that is where the entire project will either be deemed a success or failure.  There is very little ground in the middle.  If contingencies have been planned throughout the project, it will likely be a successful implementation.  Otherwise, it could be a nightmare.  The implementation will be a culmination of not only the smaller successes along the way but also a culmination of the smaller failures made along the way.

When things go wrong during implementation, they are either from mistakes made much earlier in the process or they are things over which no one would have reasonably planned.  Implementation issues are rarely exactly that, as even the planning for implementation needs to take place before the actual event.

Technorati Tags: project management,information technology,it pm,implementation,making things hard,herding cats,complications,overcomplicate,complex,need to simplify,break down,manageable,components