You Want IT When?

Is formal project management necessary to successfully deliver a software project?  The short answer to that is no.  Many successful software products have been launched without any project plans or schedules, at least not in the traditional sense.  When I first started in this field, project plans were not the norm, but that was when programs fit in a device with less than one megabyte of memory. 

(more…)

Purpose 

To clarify some possible misconceptions about the goal of this article series, it is NOT to advocate that there should be unrealistic schedules.  Quite the contrary, I don’t support expecting a team to deliver herculean efforts.  It’s an unsustainable model.  However, dates and requirements are often forced upon software teams, and they often have little ability to influence the commitments, both in date and content.  The goal of this series is to outline a model to successfully manage through these challenging circumstances for the benefit of the company, the team, and yourself.

(more…)

Management Approach

I’ve identified eleven tasks that I believe are essential for delivering to an unrealistic schedule.  While the tasks are numbered, they signify a loose priority.  It’s not intended for them to be followed exactly one after the other except for the first two.  The first two are the most important of the tasks, and the approach hinges on the first two for this to be successful.  When you’ve completed the first two tasks you’ve essentially identified your strategy.

(more…)

You’ve probably been there, working to deliver on one of those unrealistic schedules.  They all roughly follow the same trajectory.  The marketing team sponsors the next project with a must hit inflexible date, an inflexible set of must have requirements, and an inflexible fixed budget.  As the software manager responsible for delivering the release, you attempt to bring some reality to the situation, but you instantly conclude it is hopeless: there’s no changing your circumstances, and if you continue to try, it will only harm you. 

This is when many mangers make the fatal mistake: they immediately start the team coding.  There is no time to plan, no time to document, no time for meetings, no time for reviews, and no time for unit testing.  There is only time to code it, build it, pass it to QA for testing, find defects, and repeat the process until the release date. Then, someone makes a decision to either release it as is or slip the date and apply more pressure.

(more…)

What’s your worst fear as a software professional? My worst fear is changing jobs and joining a team that is in crisis. You’ve probably been part of a team, heard about a team or witnessed another team in your company deliver to one of those unrealistic schedules.  Often times, the project starts off right, but entropy slowly builds as changes are introduced to the schedule with the velocity of an open fire hydrant.  It doesn’t start that way: it builds with a crescendo.  It’s not a case of replacing the old water with new water; it’s a case of filling a pool that’s filled 98% of capacity while watching the water spill over the sides and drain into the streets.

It’s not the fear of working hard, long hours, or getting my hands dirty that concerns me - in fact I find crisis invigorating - it’s whether I’ll be empowered to make the changes required to right the ship that concerns me most.  There’s nothing like the feeling of dread when participating in an endeavor that controls your life because the leadership is making mistaken decisions that you believe are the root cause of your undesirable circumstances: the kind of decisions that dig the project into a deeper and deeper hole.

Well it happened to me when I started a new job as a Software Development Manager in 1999.  When I arrived at the office on that first Monday, I was the first one to arrive, and when the first veteran employee arrived, he greeted me with the traditional first hellos and said, “yeah, the guys will be strolling in late today, they just worked through the weekend.”  I knew instantly that things were going to be interesting, and I was not to be disappointed.

(more…)

Does your final project schedule look identical to the project schedule that you began your release with?  If it does, you either aren’t managing your schedule or you are working on a dead product.  Project Management is predominantly an exercise in change management - so much so that I like to think of them as synonyms for one another. 

There are two primary sources of schedule change.  One source is when the actual productivity doesn’t match the budgets in your work break down structure.  The other source, the more problematic source of change, is when your requirements change.  This article will concentrate on managing changing requirements.

(more…)