Six Keys to Successful and Productive Software Delivery

February 14, 2009

This blog follows up on my last post, Performance, Productivity, and Results Defined. At the risk of stating the obvious, I’ll provide my take on the essential keys required to achieve true productivity and to generate value.

Key #1: Know Your ROI
Every software project involves people; and since there will be an investment in time and effort of these people – well-paid knowledge workers – to build the actual software, there should be some up-front thinking and analysis performed to determine that there will be a sufficient return on the investment.


Part of this analysis should consider the high-level features and capabilities desired, with a prioritization of those features and capabilities that will provide the greatest benefit. Why? Because there are far too many software projects are regarded as failures, as reported in Failure Rate.

When it comes to software, smaller projects are definitely better, as smaller projects improve your chances for success. And if they are going to be small, those projects should concentrate on delivering those features that drive the greatest benefit. This will also contribute improving results and productivity as noted in my next key.

Key #2: Customer Involvement
Software projects can go awry for any number of reasons, but one major reason centers around the requirements – the business end that the software is meant to meet in the first place! Customers absolutely need to be involved in the feature specification and design process, and ideally participating with the software team throughout the development cycle.

Consider the following data points drawn from industry gurus Steve McConnell and Karl Wiegers:
  • Requirements defects in software projects account for approximately 50% of product defects.

  • The percentage of the re-work on software projects due to requirements defects is greater than 50%.
These points are significant in their own right, and I feel that this places requirements in a class by itself. Mismanagement or inattention in this area alone will force the overall costs of a project up while driving the quality, satisfaction, and ultimately the value delivered sharply down.

Key #3: Hire and Retain Capable, Competent People
In his book Good to Great (© 2001), Jim Collins asserts “Get the right people on the bus, the wrong people off the bus, and the right people in the right seats – then figure out where to drive it.” So just what do the “right” people look like?

My take is that there are some specific skills and abilities that are exhibited by top performers, regardless of whether they are programmers, quality assurance testers, managers, writers, or anyone else in any other role. My “top skills and abilities list” is as follows:

  1. Motivation.

  2. Critical thinking skills.

  3. Communication and collaboration skills.

  4. Demonstrated drive for continual learning and exploring.

I have two more that are desirable, and contribute to overall higher productivity and effectiveness:

  1. Domain knowledge.

  2. Experience.
When you have great people working for you, you’ve positioned yourself for success right out of the gate. I’ve seen great people working with great teamwork overcome some ridiculous hurdles in the past. Software is a people-intensive business, and you need great people to succeed.

Key #4: Prevent Defects
Key #2 stressed the need for customer involvement and getting the requirements correct, as 50% of the product defects in software projects can be attributed to requirements problems. Preventing the other 50% of product defects – or at least catching them as early as possible – pays a dividend as well. A general industry assessment is that finding and fixing a software problem after delivery is 100 times more expensive than finding and fixing early on, in the requirements or design phases.

Check out the following chart to see how costs drive upward – and increasingly so – the further into the software phase you progress:

There are supporting best practices in the software industry to prevent defects:

  1. Conduct design reviews, checking to ensure that there is alignment between business requirements, system architecture, and test scenarios. There should also be a check to ensure that software re-use and the incorporation of design patterns to solve common programming problems are planned.

  2. Conduct automated and manual code inspections, checking for – and preventing – the implementation of high-risk code. This means ensuring that the code does not contain any overly complex routines, that it is commented, clear and maintainable, that any planned software re-use and design patterns were implemented, and that proper error handling and security requirements have been addressed.

  3. Test, test, test! Test early, test often; keep the quality up by conducting rigorous tests throughout the software life cycle. These include unit tests and feature tests. Naturally, the more automated your tests, the more productive you will be.

Key #5: Teamwork and Collaboration
Today’s world is more demanding than ever before. We’re tackling harder software projects that involve interconnections and interactions between other systems and devices that require people to communicate and work together. In the early PC days, it was much easier to be the single and only expert – hardware, software, telecommunications – but those were simpler systems.

Technology has advanced significantly and will continue to do so, forcing specialization and focusing efforts of individuals. Delivering sophisticated applications that communicate with each other and expose interfaces in a wired (and wireless) world demands teams and collaboration.

While your personal productivity may require some “quiet time,” there is a need to work and play well with others. The days of being a solitary programmer with people sliding pizza under your door – because you can’t or won’t play well with others – is over.

For some people, working as part of a team is a challenge. I’ve seen people who are supposed to be a part of a self-organizing team choosing to optimize their own work to the detriment of the team as a whole. There can be reasons for this. Perhaps management is evaluating people on their individual assignments to the extent that teamwork takes a back seat; other times a simple coaching exercise is required – with the focus on the team and the team’s results being emphasized.

True teams, once they start to gel, can be an overwhelming force. People assume responsibility for their tasks, take on tasks that are outside of their own areas of expertise when a need arises, discuss and white-board options to solve difficult problems, and in general make each other more effective than the sum of the parts.

Key #6: Management and Organizational Support
The tone that is set – the organizational culture – and the methods that management uses to manage people can play a vital role in the continued success of an organization. You can achieve short-term success by driving people with “death march” projects and micromanagement, but in general you run the risk of driving good people straight out of your organization through mismanagement.

Determining and communicating organizational priorities and objectives so that they are understood, setting expectations of individuals and teams – and ensuring that performance evaluations and recognition systems are aligned with the organization’s priorities and objectives – is vital. Equally important is finding that middle ground between micromanagement and being completely disconnected.

Knowledge workers in general do not like to be micromanaged, and in fact find it to be a great disincentive. Personally, I feel that micromanagement introduces productivity problems in general. If you insist on micromanaging, people that work for you will always look to you to provide the definition of the work, but they will not contribute any value-added thoughts that could make a meaningful difference. They will be conditioned to providing what you ask for and only what you ask for – which means everything revolves around the micromanager.

On the flip side, some managers are so distant from the work being performed by those that they manage that little to no important conversations ever take place – a strange dynamic. Too often, people complain that they only have meaningful conversations with their boss at the annual review. And I’ve been involved with management teams in companies where management clearly didn’t understand the specifics of the situations that their people were involved in, but they were very willing to weigh in on what they wanted to see happen. Of course, many times the direction was less than optimal, and certainly could have been much better if those in management had engaged in a dialog designed to truly understand the situation before making a call.