Random Acts of IT Project Management

Project Management for Information Technology

Posts Tagged ‘making things hard’

Seth Godin and One Thing

Posted by iammarchhare on 8 July 2009

Seth Godin had a couple of good posts last month that are worth a read.  Both are about concentrating on one or two things that make a difference.   First, you must identify the key thing you should be focused on.  Second, you must ensure you aren’t spreading yourself too thin.  The second is particularly relevant for job seekers in this economy, but there is a larger principle as well.

One post was “Ruby slippers”.  Do you know what the one thing even is that you should be concentrating on?

If you could make one thing come true that would change everything for your project, do you know what the one thing would be?

There are a lot of companies that don’t know what they want, so they inevitably fail.  Been there, done that, and it ain’t no fun!

The other post is a little longer and is about “How big is your farm?”  This one particularly hit home because of all of the “experts” that want you to get out and network here, network there, be on this social site, be on that social site and run yourself ragged for some pretty iffy payback.  Double that if you are looking for full time employment and not consulting gigs.

The number of media channels available to you keeps growing. The number of places you can spend time and money is almost endless. Yet your budget isn’t. Your time certainly isn’t.

Some people would have you spend a little time on each social network, run ads in ten or fifteen media, focus on one hundred major markets and spend time on PR and publicity in every publication willing to listen to you.

You know, it never ceases to amaze me how people react when I give them simple answers to what they perceive to be complex questions.  They are making it hard.  What do you do when customer Z wants something, but you are working on customer A’s project?  That’s easy!  Which one has the priority?  Pick one and do your best on that endeavor.  You cannot do your best work by juggling 26 different projects.  You cannot even do acceptable work by juggling 26 different projects.

I used to have a product manager that had the philosophy that you should not be afraid to fire a customer.  If the customer required too many resources, made unreasonable demands or just wasn’t living up the ROI, it’s probably time to fire that customer.  Spend your time and your money on the customers that matter.  Make sure catering to that customer brings you something you need.

Usually, it’s about this time that people get flustered and start on, “Well, how do you choose which customers don’t get what they want?”  When I respond with, “Well, what is your business strategy?”, about 90% of the time it turns out they don’t really have one.  They don’t know the ROI because they don’t know what R they want for their I.  Is it prestige?  Cash?  Other goods and services?  What return do you really need from this customer to keep from firing them?

Each of us has 24 hours in a day.  The rich don’t get more, and the poor don’t get less.  How you spend that time says a lot about your priorities.  What are your priorities?  Do you know?  Are you following through on them?

Posted in Business Strategy, Leadership | Tagged: , , , , , , , , , | 1 Comment »

Should It Be Hard?

Posted by iammarchhare on 29 June 2009

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.

Posted in Business Strategy, Consulting, Requirements, Risk Management | Tagged: , , , , , , , , | Comments Off on Should It Be Hard?

Don’t Make It Hard!

Posted by iammarchhare on 30 April 2009

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.

Posted in People Management, Risk Management | Tagged: , , , , , , , , , , , , | 6 Comments »