You Want IT When?

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…)

You’ve probably heard someone say it, or you may even say it yourself:  “You design quality into a product; you don’t test quality into a product.”  The last time when I heard those words uttered, I had to restrain myself from reacting.  What did this person mean by that?   The product was in trouble.  It released late and with low quality.  Customers were rolled back to the former version, and now the product marketing team fears that if things aren’t corrected soon they will lose market share.

(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…)

I often wonder why software teams always seem to be committing to unrealistic schedules.  You know when the sales team signed a contract with a customer to deliver functionality on a date without ever asking the engineering team whether it were possible. Never mind the roadmaps identify an entirely different set of functionality than what was committed. And guess what?  The product roadmaps can’t change either; the sales team has signed contracts on that functionality too.

It’s not just the sales organizations though; the software organizations are all too happy to over commit without any help from outsiders.  You probably have one of those programmers on your team that when you ask him for an estimate, he says a week and three months later he’s still working on it.  When you ask him what happened, his answer is well it was a bit more complicated than I thought.  Does he learn from it? No way. Ask for an estimate on the next project, and he’ll still quote a week.

(more…)

It happened when I participated for the first time on a SEI/CMM process improvement initiative at my employer.  That’s when I realized the power of software metrics.  Instead of handing us a ready made process to follow, each of the different product organizations were tasked with the objective of developing their own processes with the goal of achieving Level 2 certification.   Each group formed teams around the key process areas (KPA) to develop the practices to be followed.  It was without a doubt the best process improvement experience of my career changing the way I manage and view software management permanently.  

When the process areas were complete, it was then my responsibility as a Technical Project Leader to use the processes developed on the implementation of my next assignment.  While there was skepticism with the initiative, the organization I worked in decided that they were going to support it and give it a good college try, and we did.  Some organizations simply wrote the procedures and loosely followed their processes, which is more often the case.

That’s when the epiphany happened.  One of the key principles for estimating is to first size the project and permute the size into a duration using historical data or industry standard data when no historical data exists.   Since we never recorded this type of data before, we used industry standard data, or what we believed to be.   Once the estimates were developed and work began, the power of that approach revealed itself when I began to track the project.  The tracking KPA required that all estimating assumptions be tracked, both time and size.

(more…)