Random Acts of IT Project Management

Project Management for Information Technology

Posts Tagged ‘PM Basics’

Taking Over the Loser Project

Posted by iammarchhare on 27 August 2009

In case you missed the comment, The Corporate Sleuth over at the Survive and Thrive in the Corporate World blog posted “Myth: Loser Projects are for Losers“.  The author makes a decent case that the “black hole” projects give you a chance to showcase your PM skills.

Yet, the main issue I see is that you usually don’t get a whole lot of choice in the matter.  It tends to be do or die, and sometimes you just pull the short straw.  What I recommend in any event, on any project, good or bad, is to do your best.  Like my father used to say, “If you did your best, then no one can claim you didn’t try.”

Posted in Troubled Projects | Tagged: , , , | Comments Off on Taking Over the Loser Project

A New PM Resource: The Lazy Project Manager

Posted by iammarchhare on 13 August 2009

I came across a unique resource called “The Lazy Project Manager”.  While it is a serious discussion about a serious topic, the website is anything but dry.  While the sentences can be somewhat tongue-in-cheek, it provides a unique look at project management.

Apparently, the website is based upon the book The Lazy Project Manager by Peter Taylor, a speaking and project management professional based in London.

“Lazy” is used in the sense that focus is placed where it counts.  “Lazy does not mean Stupid.”  “Lazy does not mean Unsuccessful.”

My only real gripe about the site is that, in Firefox at least, the homepage has a huge gap in it, and, if you aren’t paying attention to the scrollbar, it is easy to miss the fact that there is more information near the bottom of the page.

Anyhow, I’ve only been through about 1/3rd of the pages, and it is an interesting read.

Posted in PM Basics, References & Resources | Tagged: , , , , | 1 Comment »

A Little Common Sense Goes a Long Way

Posted by iammarchhare on 17 June 2009

Remember that I said, “Don’t Make It Hard”?  Well, it is interesting to note a non-PM’s common sense approach to project management.  In “Project Management Made Easy”, D Keith Robinson wrote:

I think one of the biggest problems with many project managers is that they over complicate things or they force you into an overly ridged or complicated process. This makes everyone’s job harder. The idea is to work on the project, not for the project.

I think Robinson is oversimplifying things a bit, but keep in mind it is important to achieve a certain balance.  Project management should extend beyond just being on time and under budget.  It should also be about future reinforcement of what went right and avoidance of what went wrong.  It should be about sticking with what works.  A huge process that hinders work and adds no value should be thrown out.  A lightweight process that produces low quality products also is in dire need of amendment/replacement.

Posted in PM Basics | Tagged: , , , , | Comments Off on A Little Common Sense Goes a Long Way

Ambiguous Scope

Posted by iammarchhare on 11 May 2009

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.

Posted in PM Basics, Risk Management, Troubled Projects | Tagged: , , , , , , , , , , , , , , | 2 Comments »

What Is the Most Important Part of a Project?

Posted by iammarchhare on 22 April 2009

Most of the time, a project manager will say “requirements gathering”.  Once upon a time, I probably would have agreed.  But, I don’t any longer.

Toni Bowers of TechRepublic posted on the IT Leadership blog “Five reasons to discuss project failure”.  She writes:

  1. Failure is instructive. Most of us have an instinctive aversion to discussing weakness, based on concerns that criticism may hurt our pride, reputation, and so on. While I deeply respect these sensitivities, fear creates an environment where repeated cycles of failure can manifest. Breaking this cycle requires understanding the source of problems followed by developing solutions to address them.

Failure causes you to learn.  Hopefully, success does as well.  Humans have an amazing capacity to learn, and we should do so at every opportunity.  If we do not learn, we do not improve professionally or grow personally.

Teams and even companies can learn as well.  That’s why Bowers’ article is so important.  If teams and companies cannot face the facts and learn, then they never improve.  Projects will continue to fail.

A thorough “lessons learned” or “after action” review is a must.  The US Army has a tradition of sending soldiers on field exercises and then holding after action reviews afterwards to grade themselves.  Self-reflection is the key to improvement.

That’s why in the long run requirements gathering just plain is not as important!  Why?  Because a thorough lessons learned review will uncover it as a weakness and make recommendations to fix the problem.  If you do lessons learned poorly or not at all, you will never know if your requirements gathering is any good or not!

What if you had a project to create a product, it was done on time and under budget, it was delivered and the customer never complained.  Was the project a success?  How do you know?

There is a saying that for every customer that complains, there are 9 others who have the same problem but do not complain.  It could be because they are too busy or too tired, or maybe they don’t know who to complain to.  Just because no one complains does not mean the project was a success.  Again, you have to gather data after the main portions of the project have been completed.

The fact that I’ve changed my mind about “requirements gathering” is proof I’m not too old to learn.  🙂

Posted in PM Basics, SDLC, Skills | Tagged: , , , , , , , , | 1 Comment »

Book Review: The Dip by Seth Godin

Posted by iammarchhare on 17 April 2009

The opening of The Dip: A Little Book That Teaches You When to Quit (and When to Stick) by Seth Godin goes like this:

I feel like giving up.

Almost every day, in fact.  Not all day, of course, but there are moments.

~ p 3

Thus, I was immediately drawn in.

For a high-level philosophical viewpoint, I think Godin gets his point across quite well.  For a low-level practical standpoint, though, I’m not so sure.

However, since it is a high-level look, it can apply in so many areas.  It can apply personally or corporately.  It can apply to marketing, general management, IT, or any area where you might have a goal.  It can apply to a corporate strategy or a career path.

Types of Obstacles

Godin outlines 3 types of obstacles:

  1. The dip.  This is what separates the experts from the amateurs.  It takes resources to cross the dip, to get back up the hill and succeed.
  2. The cul-de-sac.  This can also be called the “dead end”.  No amount of effort is going to get you where you want in this space.
  3. The cliff.  You climb up and up, but then you suddenly crash.  A disaster is the result.

I think we can all think of examples of these.  Godin gives the example of passing organic chemistry as the dip for pre-med students.  Getting past HR might be a dip for a job seeker.  A dead-end job is a cul-de-sac.  Cigarette smoking is a cliff.  You puff along and puff along, and all of a sudden you’re dealing with a life debilitating disease like emphysema.

Basically, his advice seems to be that as long as it is worth doing, it is a dip.  If it is not worth doing, then it is a cul-de-sac.  If it is a dip, keep persevering.  However, one should be more than willing to quit for cul-de-sacs and cliffs.

It’s easy enough to say that one should quit if it is a dead-end.  Godin tells of people who quit because they did not cross a dip, though.  Instead of quitting a cul-de-sac, they quit in a dip.  I’m just not convinced that he gave clear enough guidelines to distinguish the 2 in a practical situation.

Woodpeckers and Diversification

Throughout the book, Godin argues that diversification takes away energy from other pursuits.  It takes resources away from the energy that’s needed to overcome the dip.

A woodpecker can tap twenty times on a thousand trees and get nowhere, but stay busy.  Or he can tap twenty-thousand times on one tree and get dinner.

~ p 29

This analogy breaks, though.  What if there is no dinner to be found in that tree?  The woodpecker starves as much by trying too little in a thousand trees.  I think he tries to address that later on by stating that you should write down the circumstances in which you’ll quit, but this question just screamed out at me when I was reading the book.

The other problem, of course, is that especially in the IT world, you have so many options that it can be hard to narrow them down.  Sometimes you really do have to experiment with different things and ideas before you find something that works and works well.

Cul-de-sacs and Space Shuttles

Godin argues that the space shuttle is a cul-de-sac and not a dip.  It exists because “no one has the guts to cancel it”.

Perhaps he is right.  After all, what is the goal of the space shuttle?  What are we trying to accomplish?  I mean, NASA had a goal when it was trying to be 1st to the moon.  Those were exciting times.  From what I understand, even the space station is likely to be abandoned in the near future, so what should we be trying to do with space?

Does that make it a cul-de-sac, then?  It does seem pretty dead end if you don’t have a goal.  However, if there still were a goal, would it still be a cul-de-sac?  That part isn’t clear to me.

Flexible Dips

To me, it gets even more confusing then, as Godin presents dips as not being concrete objects.  They are subject to change.

Microsoft, for example, was able to create a dip by becoming the standard.  They themselves overcame dips by persevering with Windows, Word, Excel, etc.  They failed a few times before they won.  Now, the dip has become much larger for those who follow.

Yet, what might appear as a cul-de-sac really is a dip.  Microsoft products run on Microsoft platforms.  Google is now a challenger because their products are online.  In other words, Google is competing on a different platform.

His point is that to overcome a dip, you must act.  It isn’t something you ride out.  You must engage it.

Then, he states that quitting in the dip is a mistake usually based upon short-term concerns.  Here I think, then, is what probably is the key to dip vs. cul-de-sac.  One is a short-term problem that can be overcome and even changed with effort and insight.  The other is long-term and immovable.  I really think not stating this concretely and earlier in the book is the book’s biggest weakness.

Sunk Costs

Godin presents a Harvard Medical Degree as an example of sunk-cost.  Someone who is studying medicine but cannot stand to cut someone open is probably not going to make a great surgeon.

I actually think he could have emphasized this even more.  I’ve been thinking about sunk-costs since reading a post about the sunk-cost fallacy on the blog Get Rich Slowly.  It’s surprising how much it motivates our decision-making.  The problem with it, though, is that it can lead to “throwing good money after bad” instead of knowing when to quit.

How many IT managers have been afraid to shut down a project because some executive wanted it?  How many executives have been afraid to stop a bleeding project because they perceived that was what the customer wanted (when in fact it might not be what they need at all)?

Before You Quit and Before You Start

Perhaps the most practical sections of the book are “Three Questions to Ask Before Quitting” and the one immediately following called “Quitting Before You Start”.

The 3 questions:

  1. Am I panicking? — don’t decide things when panicked
  2. Who am I trying to influence? — markets vs individuals
  3. What sort of measurable progress am I making? — sticking with a situation in spite of forward progress is a waste

He then spends some time on tactics vs strategy.  Quitting a job is not giving up on making a living, for example.  A job is a tactic.  It gets you to where you want to go.  If it doesn’t, then it is time to quit.  Again, I have to believe the difference is short-term vs long-term here.

To me, though, the most valuable part of the book is to write down the circumstances in which you will quit.  This really seems to differentiate the dips from the cul-de-sacs.  An athlete isn’t going to quit because of a bruised knee.  A congenital heart condition might be a good reason to quit, though.

This points out why I say it is more of a philosophical book than a practical book.  The specifics are going to depend upon you or your team as well as your environment.  In the end, it seems to me only you can truly distinguish the cul-de-sac from the dip.  In addition, there are sections of the book that speak of creating your own dips.  In theory, then, even a cul-de-sac might really be a dip in a different market.  Thus, if you can create your own market, you have a distinct advantage.  It just isn’t cut and dried.

In project management, a team really needs to decide upfront what constitutes a failed project and how to pull the plug on it before more money goes down the toilet.

Wrapping It Up

It seems appropriate that there isn’t a neat bow to tidy things up at the end of the book.  Rather, it ends with a lot of questions.  These questions should guide you to further thinking on the subject.  I’ll let you read the book and answer them yourself.

Posted in Book Review, PM Basics | Tagged: , , , , , , , , , , , , , | 5 Comments »