Delivering Results: It Starts at the Top

January 24, 2009

In order to deliver a successful software project, everything has to go right at every phase, with everyone contributing at every level. I’ve seen problems with software projects that can be traced straight back to the management team. From the outset, it is useful to ask: Has management thought through its business objectives and articulated those objectives? And how does a particular project relate to those objectives?

Software development is a classic “knowledge worker” endeavor, and those knowledge workers involved with delivering projects need information as input, otherwise you run the risk of a team making day-to-day decisions that will work against your intended purpose. In today’s tough economic conditions coupled with global competition, focusing on delivering the greatest value for the dollar invested is of paramount importance.

A big problem area in software is prioritization. What features will provide the maximum benefit? You want to ensure that software teams are working from a prioritized feature list. Without one, teams can spend significant time and effort delivering low-priority features.

A software team lacking an understanding of priorities (and the desired benefit) will organize their work in other ways, such as grouping the development and testing of similar features together. If someone happens to be working in one section of code, it will be considered both logical and optimal to build out two features instead of one, even though one of those features doesn’t contribute significantly to the benefit side of the equation.

I’ve personally been frustrated in the past by product managers – working as part of the management team – who didn’t effectively prioritize. I can recall asking what the business priorities were when I was presented with a list of potential features for the next release of a product, only to be told, “Tell me how long it will take to build each feature, and I’ll tell you whether we’ll include it in the release.”

You heard correctly, our “prioritization” was all about how whether something fit into the timing of a release! This lack of prioritization meant that I was tasked with figuring out how much of that list I could complete; I was judged on quantity.

Instead of focusing on those features that provided the maximum benefit, my staff spent time estimating a wide range of features, some of which we knew wouldn’t be worked on once the estimating was done. In addition, I spent my time optimizing the feature count targeted for a release, mixing and matching potential features in such a way that my staff was optimally aligned based on their skill set and availability (with their availability based on my ordering of the feature delivery).

Was this the most effective use of our time? Did we end up spending valuable time implementing features that were of marginal benefit to our company? You bet. This situation is not only a time-waster, it is de-motivating. High-performing teams and individuals want to make valuable contributions; they want to be engaged in meaningful work.

The management team, who typically is the one championing the desire for high-performing, engaged employees (I am hearing this more and more these days) needs to set the tone by attaching meaning to the work – and that means ensuring that the work being performed has true value to the company. There are two sides to the motivation coin, and management owns this side.

Related to this, I’ve had people tell me that they don’t engage in a cost/benefit analysis (these happen to be companies with in-house staff, not software companies that need to profit directly from their efforts). Companies that fail to perform a cost/benefit analysis are failing in prioritization; they are likely keeping their staffs very busy, but are they being as effective as they could be? Bottom line: it pays to perform a cost/benefit analysis to ensure that the intended benefit is worth the investment.

After all, in tough economic times like this, companies everywhere are looking to be more productive, right? Before sponsoring a project you should understand the business goals of that project, the benefits you expect to derive, what investment in time and money is acceptable, and communicate that information to the software team. At least you should if you want to everyone involved to understand the results that you hope to achieve and expect people to be motivated in achieving those results.

Teams that understand the business objectives, key benefits and constraints can help shape the success of the project. Let’s face it, software projects are expensive, and if results are what you want, share this information! Knowledge workers armed with information and motivated towards achieving meaningful goals can contribute towards the outcome in one of two possible ways:
  1. The team can offer up ideas that shape the ultimate solution being delivered, generating ideas to leverage technology in new ways. Don’t – and this is a big DON’T – be married to your initial concept of a solution! Be open to suggestions early on in the process. It can pay big dividends in terms of the overall success of a project, and may even allow you to exceed expectations instead of just meeting them.
  2. The team can determine that the project as defined cannot be delivered within the time and/or budget constraints that would deem it a success. Be prepared to listen here, and be prepared to make adjustments. Perhaps there are characteristics about the project that can be reduced or simplified in order to reach the business objectives. If something is going to cost more (in some cases, far more) than the anticipated benefit, wouldn’t you want to know this before getting so deep into the project that you felt that you just have to keep going, despite the cost?