Life of a Software Program Manager

A first person accounting of what it is really like to manage a commercial software product.

SDLC in the Real World

Posted by Program Manager on June 7, 2006

SDLC – System Development Life Cycle (SDLC) – a methodology used to develop, maintain, and replace information systems.

I’ve run into more than a few project managers, developers, testers, and product managers that have caught the SDLC buzz word fever. They’ve either latched onto the newest, latest, coolest, hippest methodology, or they read in a book that you can’t succeed without one, or (most likely) their manager said that they need to have one. However they get to this state of mind, they usually follow the same course of action.

  1. Go to bookstore and buy 1 book
  2. Read at least the first few chapters of said book. Some even make it all the way through
  3. Go to their next team meeting, and declare that they are implementing an SDLC. No one else can ask questions or offer input, because the book says it will work exactly as its written
  4. Meetings are called with subjects that mysteriously match the book’s chapter headings
  5. The rest of the team has no idea what is going on, but they are following their enlightened SDLC leader blindly. It still seems like they’re writing and testing code, so at a granular level, most everything seems to be the same
    …… The Project Continues …..
  6. Utter chaos ensues, the product is late, the quality suffers, and it is deemed that SDLC’s are worthless
  7. Team reverts to prior process, and ships with previous efficiency, tracking, quality issues, and date slips. While that may sound bad, they still ship and shipping software is a key test of success or failure in commercial software.

So where does the value from using a methodology come from? For me, it all comes down to one thing: change management. If there was only one programmer, and he knew the customers, wrote the requirements, wrote the code, tested the code, fixed the code so it was bug free, packaged the product, and shipped it, there would be no need for an SDLC. OK, now back to the real world. Requirements change. Team members quit. Testers miss bugs. Developers write more bugs when they fix the bugs QA already found. Customers can’t articulate what they want. The list goes on and on. This is where having a defined methodology helps. It gets your entire team on one page. When someone falters, everyone knows, and everyone understands the impact of what that means and can adapt. It is not a blame issue, but one of good communication. When you have a team driving toward a common goal, working in a common way, helping each other succeed, then you have a team with a shared vision. A team with a shared vision can do amazing things. They can have requirements change at the last minute, and everyone knows where to help, who is impacted, and how to react. The same scenario goes into effect when someone on your team leaves. Normally, the team is lost for a bit. Some piece of critical information or a critical process lived only in that person’s head, and now that they are gone, the team is lost. Again, common steps, common process, common knowledge, shared vision, and teamwork. All of this leads a team to be adaptable to change, and having a team that can adapt and manage change, rather than letting the changes manage them is key to large scale success in software.

Having a team that can adapt and manage change, rather than letting the changes manage them is key to large scale success in software

Then how does all of this apply to me? I’ve been through a handful of projects, and I’ve learned the most important lesson about SDLC: No SDLC is perfect. All of those books look really good in print, but they are all based on best case scenarios and case studies. The key is to learn as much as possible, study many methodologies, and adapt a methodology to your team. I have a personal methodology that I usually try to follow, with parts taken from a few different communities, but with each new team and each new project, the process is adapted. The value of a process is to help organize your team, not to organize your team according to the process. There is always pain, resistance, and adaptation when implementing change, but it should be for the betterment of the team, not because you are trying to fit the team to something from a book.

This is the general methodology that I have used successfully in the past. It is a combination of a traditional waterfall development cycle, but focuses on short term, iterative deliverables during the development cycle. These are similar in principal to sprints from the SCRUM methodology (my personal term is protocycles), but with a different up front planning process. There are also aspects of XP and MSF woven throughout, but I won’t get into that many details in this post.

  1. Establish high level requirements. These need to be detailed enough that the technical design can be built from these requirements. This deliverable essentially drives the vision for the release. A 3 release roadmap is also required, so that the development team can understand what the future product plans are, with as much clarity as possible.
  2. Define the detailed requirements. This task takes the high level release requirements, and drills down to a sufficient level of detail required for the development team. As each detailed requirement document is completed, it is sent for peer review and acceptance by a representative from development, quality assurance, architecture, product management, and development management. This task happens in parallel with the technical design.
  3. Define the technical design (Architecture). Based on the high level requirements, establish a product architecture taking all three releases requirements into account. The architecture deliverables for version 1 should be at sufficient detail for the development team to use, and mock architectures should be vetted in order to validate feasibility for the version 2 and version 3 requirements. This task happens in parallel with defining the detailed requirements.
  4. Product Development. The development team executes the detailed requirements and the technical architecture. This process is somewhat agile in nature, since features can be started once the specification for that component is complete, rather than waiting on an entire requirements package.
  5. Quality Assurance. The QA team validates the software created by the development team meets the defined requirements. Test cases are created for each completed requirements document, following its peer review acceptance. For a test engineer, the requirements should read like a contract, validating that development met their end of the contract. As is typical during a development cycle, requirements will change. These will be handled as requirements addendums or modifications.
  6. Release to Manufacturing. This is the final step in the process. Once a product is ready to be delivered to market, this step represents the processes preparing for general availability. Depending on the organization, this could include source code escrow, marketing coordination, gold CD creation, retail packaging, etc… The timing for this process is generally organizationally dependent.

There it is, how to ship software in 250 words or less. I’m not trying to demean what any of us do, but at the end of the day, it all sounds so simple, doesn’t it? Define what you want, research it, document it, code it, test it, give it to people who will pay you for it.

Technorati : , , , , , , , ,


Posted in program management, Software development | 2 Comments »

More Reading for Development Managers

Posted by Program Manager on June 7, 2006

I've read Jack and Freakonomics. Not a bad list. I'll add to this in the near future with my pics.


Posted in program management, Reading, Software development | Leave a Comment »

Google Introduces a Spreadsheet – Competition for Microsoft

Posted by Program Manager on June 7, 2006

There's plenty of press about this one, but I thought Scoble had a good quote:

I want better software. Competition brings better software. It gets product managers to worry about customers. It causes discussions of features that were long-ago decided on.

If you want to see the other articles, click here.

Posted in organization, Reading, tips | 1 Comment »

Good Reading for Development Managers

Posted by Program Manager on June 7, 2006

I try to spend a few hours a week reading articles on the web. To me, the word "article" has a loose definition, but basically anything someone has taken time to put together that adds knowledge or value, I'll read if I can stumble across it. Here are this week's selections:

Posted in program management, Reading, Software development | Leave a Comment »

Good Reading for Software Architects

Posted by Program Manager on June 6, 2006

My background is in software development and architecture, so here are some good blogs that I try to read regularly.

Posted in program management, Reading, Software development | Leave a Comment »

Read RSS on your Windows Mobile Device with AvantGo

Posted by Program Manager on June 6, 2006

AvantGo has finally released an updated reader for Windows Mobile devices that supports RSS. Find the full story here at Download it here.

Posted in Windows Mobile | 1 Comment »

Defect Count is a Constant

Posted by Program Manager on June 6, 2006

One of the most inspirational people in software that I've come across is Jim McCarthy. I had the privledge of seeing him give a presentation, and he had a few quotes that made a lot of sense. The one that really stood out to me was

"Defect count is a constant."

This became very clear to me last week, as my team went through a Bug Bash. In 48 hours, we closed out over 400 defects, but the number of defects open with development stayed almost level. I could go into the details of the defects, such as priority, severity, category, and so on, and we did make some substantial progress, moving our average defect severity from critical to medium, but at the end of the day, all software has problems bugs defects. And this was one of the most difficult lessons I've ever had to learn:

Shipping software is an act of reality, not a pursuit of perfection.

This lesson was extermely difficult since I come from a development background, I always want my software to be perfect, to be bug-free. Unfortunately, the larger the project, the less control that you have over it. As a manager, your job is about steering the ship, and you have to trust that your staff is all rowing in the same direction. There are things you can do to get more involved with the low level tasks, and I recommend that you do, but at the end of the day, you can't spend 40+ hours per week with each member of your team (Trust me on the math, after 4 employees, this model doesn't scale). In the world of software management, you need to accept a product that is less than perfect, and understand what is critical to ship and what is not. I'm not saying that you should ship a garbage product, but at the end of the day, if a new feature isn't ready, you can probably cut it, ship the release, and your world will not come to an end. Note the exception list here is long, like if the feature is contractually committed, or highly marketed, or the center piece of your release, etc…

I added some links at the bottom for more informaiton about Jim McCarthy for your reading pleasure.

Jim McCarthy – I highly recommend that anyone involved with shipping software, expecially in any leadership position, should check out Jim's book and video if you can get your hands on it.

Posted in program management, Software development | Leave a Comment »

The Value of Product Management

Posted by Program Manager on June 6, 2006

When I started out, I thought that it was critically important for each developer to know all the ins and outs of the end user. If you are writing a financial application, the developer should be able to pass for an entry level accountant. Well, then I got into healthcare, and I realized that it’s impossible for developers to know anything close to what an end user knows. This is when I saw the light on the value of product management.

A great product manager will perform three tasks:

  1. Drive a product’s strategic road map. This means that the product manager understands the end user’s needs and understands the competitive marketplace. Understands which features are competitive disadvantages, market differentiators, visionary features, and customer satisfaction issues. The road map will align these features by priority and usually group them into 3 releases. A near-term, tactical release, a longer term strategic release, and a long term visionary release. Dates on these releases are irrelevant, since the road map defines what needs to be done, and then the timeline can be wrapped around that.
  2. Cut features from a release scope. Inevitably, customers, marketing, and product management will want more features than the development team can support in a given time frame. It falls to the product manager to work with the program manager and reduce the scope list (The entire scope planning process is another topic for another day). The product manager must balance the needs of sales, marketing, existing customers, and new customers to prioritize the list and make some tough decisions. A good product manager understands and accepts this. A tell-tale sign of a poor or inexperienced product manager is one who will kick and scream to make it all fit into the scope, rather than accept the constraints of reality.
  3. Understand the customer’s business. This is the most critical skill above anything else. A great product manager truly understands their customer. Usually, this means that they came out of the field that your product is now servicing. Maybe they were an account if you are developing accounting software, or a nurse if you are developing hospital software. This allows the product manager to converse with the customer in their vernacular, build a repore, and gain insight to new developments in the industry. The other benefit is that they become a key resource for the development team. The development team will not understand all of the intricacies of a particular business function, but the product manager should. And if they don’t, they’ve built relationships with key customers that they can contact to get the exact answer. This allows your team to correct an issue in the design phase, rather than waiting until it is in the hands of customers, and is 10 times more costly to repair.

The key takeaway for anyone in development is that product managers are the ones responsible for the domain expertise, and the rest of the team should leverage and benefit from that.

Technorati : , , , , , , , ,

Posted in program management, Software development | 14 Comments »

Wow, this is really cool – Stream Sirius to your phone

Posted by Program Manager on June 6, 2006

Listen to Sirius on your Windows Mobile phone. I’ve used this and it is very handy.


Technorati : , , , ,

Posted in Cell Phones, Sirius, Windows Mobile | 1 Comment »

Interesting Reads

Posted by Program Manager on June 6, 2006

I've added a link to my links section, but one blog that I've found very informative is Guy Kawasaki's ( He has written a few books, and has plenty of experience in the VC space. He posts very frequently, here are a few of my favorite posts.

  • Top CEO Lies – Link
  • Top Engineer Lies – Link
  • Top VC Lies – Link
  • Scott McNealy Top 10 – Link

Posted in Links, Reading | Leave a Comment »