Random Stats

I was a little surprised today when I was looking at Dice.com.  It turns out that there are only 3072 results for “project manager” in the US.  Of those, 2060 are in “development”.  I really expected a higher percentage to be in infrastructure and/or networking.

If you are interested in locations, New York had the highest in “development” and “project manager” positions, coming in at 101.  It had 179 overall.  Even San Francisco only had 81 PM positions (less than half).  However, even then San Francisco was tied for 2nd place with Chicago.  Cleveland only has 23.  Jacksonville, FL comes in dead last with only 12.

I was originally looking for information on programming languages, actually.  Since it seems that roughly 2/3rds of us are dealing with developers or software engineers, I will share that with you as well.  I’m not trying to start another religious war about programming languages, but I did want to see what employers and clients are looking for.  Keep in mind, though, that languages are just a tool.  We may have our favorite tools, but they are still just tools.

Java – 8268 results

C# – 4036

C – 2355

C++ – 4103

COBOL – 481

Flash – 843

PHP – 1073

XML – 4337

HTML – 3155

SQL – 9168

I ended up throwing out the .NET number because the numbers just didn’t add up.  It seems to me that a lot of the HR/recruiters still don’t know the difference between .NET and C#.  Or, is there really a C# implementation outside of .NET (because I’m not aware of any)?

So, why do this exercise?  Well, if someone wanted to learn a new skill in this economy, would it really make sense for it to be COBOL?  Yes, it has its uses.  It might even be fascinating for some people.  However, if your aim is to improve your stance in the marketplace, I think COBOL should not be your target area skill set to upgrade to.  If you understand Java, perhaps it would be easier to be hired in as a project manager overseeing a Java development team.

What do you think?  Other than certification, what can you do to increase your value in the marketplace?

Technorati Tags: it pm,project management,development,programming,software,languages,value in the market,information technology,skills,tools

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

Revolutionary Laptop Breakthrough

The Onion reports on “Apple Introduces Revolutionary New Laptop“.  This video is hilarious!

Cell Phones Too Complicated?

Some of you took exception to my contention in “Microsoft Dropping the Ball?” that smartphones are losing ground in the cell phone arena because of a lack of innovation by MS.  In particular, I posited the question, “What have you (MS) done for me lately?”

Of course, the world is full of dissenting opinions, and that is one of the things that makes life interesting.  In fact, PC World just recently posted an article on 21 June 2009 that “Cell Phones Getting Too Complicated, Poll Finds”.

As they say, though, YMMV.  In the LifeHacker article “Are Standard Cellphones Too Complicated?” that contains a pointer to the above article, you see people bemoaning too many features, but some seem to have a feature set they consider essential that does not involve simply sending/receiving voice calls.

I guess “complicated” is in the eye of the beholder.  If it is viewed as a “needed” feature, then not having it is a negative.

I’m going to stir the pot even a little more, though.

I’m honestly not so sure that the future is with cell phone technology, though.  Some experts have implied that satellite technology is better and coming down in price.  Satellite phones don’t require a cell tower and can be used in the remotest areas.  Then, there are some who believe that VOIP will continue to become ubiquitous and of better quality.

Technorati Tags: technology,cell phones,cellphones,smartphone,voip,satellite,complicated,voice calls

Real Life Project Management

Steve McConnell wrote about a home project he worked on in “Building a Fort: Lessons in Software Estimation” and the take-aways he had.  It’s a neat little reminder that, consciously or not, we use/ignore project management techniques on a daily basis.

For example, there are many events can take quite a bit of preparation and planning this time of year.  Graduation parties, planting a garden and let’s not forget weddings are all competing for our schedules and other resources.

This year, many are running into a new obstacle: money.  Obviously, I don’t mean to suggest that it was ever an unlimited resources, but for many it is more scarce than at times past.  Even those who do have sufficient means are more reluctant to dip at the well because they don’t know what tomorrow might bring.

You PMs know the concept: Triple constraints.  You can control one of them and influence the other.  The 3rd will be the result of the other 2.

If you do a lot of internal projects, you can get caught in the trap of thinking strictly in terms of “estimating” a project in regards to effort and/or duration.  However, the reality is that at some point, it boils down to the bottom line.  “Time is money” goes the expression, and a project may have little effort required, but the outsourcing or off-the-shelf aspect of it drives up the cost.

Let’s face it that companies as well as individuals are very interested in the bottom line.  The controlling factor in your project is likely to be the budget.

That’s not always a bad thing.  As I go around the house, I keep thinking, “Do I really need mulch here?  If so, how much do I really need?”  Surprisingly, I’ve run into 2 other homeowners with the same exact thoughts recently.  We learn to tighten our belts and become more efficient homeowners.

Companies can learn to become more efficient as well.  Some will not.  For some, it may be too little, too late.  Some will try to ride it our, but they will either make no changes or make the wrong changes.  Others will learn to adapt.  They will learn better ways to get things done.

There used to be a time when if a person ran out of money, they simply didn’t spend any more.  Sure, you had your occasional exception that stupidly borrowed from the local loan shark, but most learned to live on less.  They had to.  It was called living within their means.

American credit had gotten way out of hand.  We thought we could borrow utopia.

What I am saying is that we don’t have to continue to be that way.  We can again learn to live within our means.  We can learn to do more with less.  We can work smarter instead of harder.  These may sound like antiquated clichés, but they are sayings that came with the wisdom of experience of another generation who faced their needs head-on.

Meanwhile, I am going to have to go to the store and get a couple of items.  One of them will not be mulch, I guess.  I will have to control the one constraint (cost) better than scope or time (duration) for now.

Technorati Tags: it pm,project management,information technology,practical,triple constraint,cost,scope,time,duration,everyday use

Stupid Estimate Mistakes

Or, rather how to avoid them.  Project management is largely about estimates and hitting them, after all.  TechRepulic did an article on the “10 ways to avoid stupid project estimates” (PDF format).  I particularly like #9:

Penalize the bad estimate, not that a task estimate is too long. When estimates are shortened, it’s generally because that shorter number is what’s expected. That is where the “If all goes well, it will take…” comes from. Be serious. When was the last time “all went well”? There’s nothing wrong with qualifying an estimate, but adding an unrealistic assumption as a way to give a bad estimate only hurts the project.

My experience has been that IT folk, but especially programmers, are an optimistic lot.  The fresher they are out of school, the more optimistic they tend to be.  Why?  In school, the programming assignments were always the type that made it easy to hit the target.  They were geared towards the topic being learned, and often the answer was spoon-fed to them.  Note, I am NOT criticizing the fact that students are not hit over the head with a huge reality stick!  However, it does shade their perceptions when they graduate.  Unfortunately, by the time their estimates get good, they tend to move into more senior non-programming roles.

Some additional methods to getting more accurate estimates:

The best case amount of time, most likely amount of time and worst case time estimates.  You know the drill here: Estimate =  (Best case + 4 x most likely + worst case) / 6.  Problem?  Many view this as a time consuming way to get estimates.  Some senior or more experienced developers may even view this as a waste of time.

Group sanity check.  If you have a mix of experienced and inexperienced developers, it might be handy to have a meeting to go over the proposed schedule before it is presented outside of a developer team.  I have seen this done twice, and I wish more organizations took the time to do this.  You have to give enough time for reviewing the schedule beforehand and create an atmosphere that encourages questions.  Problem?  It will not work correctly if management has a target date and effort already in mind, unless developers or team leads are willing to defend any deviation.

The TechRepulic paper really identifies that “reward and penalize” is one of the keys (#9).  That is, hold people accountable for estimates.  To do this, you also have to give feedback (#8).  Even at that, you won’t do any good unless you develop a culture of continuous improvement (similar to point #10).  Unless people are motivated to improve, they will not!

Technorati Tags: it pm,project management,information technology,continuous improvement,estimating

Agile Development Principles and Pareto’s Law

Helium writer Kelly Waters wrote an article on “Agile development principles explained”.  I’m going to confess that I often read others’ articles and then write my own version (Helium has authors compete for ratings under the article’s title) because I just don’t like the #1 article.  I’m not going to try to top Waters’ article, although I would have liked to have seen more in it.  It is hard sometimes to strike the right balance between too much and too little information.  In my opinion, though, this particular article should have been named “Pareto’s Law” instead.

Technorati Tags: it pm,project management,agile,development,pareto,helium

Gantter

LifeHacker did an article about how “Gantter Does Project Management in Your Browser”.  With an MS Project-like interface, Gantter is free to use.

I haven’t used it, but I do hope to give it a whirl on a non-mission critical project when I get the chance.

Technorati Tags: it pm,project management,tools,gant chart,ms project,gantter,lifehacker

A Little Common Sense Goes a Long Way

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.

Technorati Tags: it pm,project management,process,common sense,pm basics