Death By Feature

The Cutter Consortium, which has been analyzing data on software projects for many years, has found that an over aggressive feature list is the second most common reason for project overruns (the first is changing requirements). At times, trying to provide too many features actually ends up providing less (or none, in the case of a failed project).

Reducing the feature list is a key step in recovering a software project that is on the road to ruin. Paring this list to an acceptable minimum is no easy task. Reducing the list too much will produce a deliverable that is completely ineffective and serves no business purpose.

In the feature list reduction process, or more simply "goal reduction", is it essential to know who in the company sets the project goals. Any changes to the project's goals will require the approval of those who originally set them.

When reducing the list of goals to those deemed "essential", there are three basic categories to keep in mind:

• Essential: requirements without which the project will have no real value.
• Important: requirements that significantly improve the project.
• Would be nice: requirements that add things such as attractiveness, ease of use, bells and whistles, etc.

Remember: the longer you wait to define realistic goals, the less you can actually deliver.

Is Your Project A Budget Catastrophe?

E.M. Bennatan states that "a project is a budget catastrophe if the remaining projected cost far exceeds what the development organization is willing to pay for it". Or as it often is, what the sponsoring department or customer has allotted for the project.

Project overruns are often the result of schedule overruns, or of attempting to reduce these overruns (e.g., adding staff), so usually a schedule overrun is evaluated first.

A budget alarm is usually triggered if the expected remaining cost far exceeds its break-even value, however, many times this value is not given enough consideration up front.

Should the project be canceled if the remaining projected cost far exceeds what the development organization is willing to pay for it? Not always, since it was the projected cost that set off the alarm. Reducing the project scope may be an alternative, thus reducing the projected cost and allowing the project to continue. This is one of the key objectives in disentangling a software catastrophe.

Being Out Of Control

Managing a software project that is out of control is a miserable experience. It seems as everyone looks at you with anger or pity.

Many times senior management does not know when a project is out of control, or why. Too often they think that it is the project manager's fault, even when it is not. A project can be out of control for many reasons: senior management, appeasing the stakeholders, no rigor to the development cycle, etc.

Determining if a project is out of control is not always easy for in-house personnel to do. Many times it is best to bring in an outsider, much like a marriage counselor, to help evaluate and pose emotionally neutral conclusions and suggestions.

Once this has been done, the project can either be sorted out and re-started with a fresh set of goals and a new focus, or it can be shut down entirely.

Having a solid set of criteria with which to evaluate an out of control project, and the right evaluator, are paramount to the success of this process.

"Classic Mistakes"

Without knowing it, your company, department, or project can pick up bad habits. Some of these are so predictable they are known as "classic mistakes". I had a manager once who without fail would mis-manage a project, er, several of them, to the point that when faced with missing a delivery date he would hire many contract developers (this is Classic Mistake #5) to pull his fat out of the fire, but it never worked.

The legendary Steve McConnell's excellent list should be on every manager's office wall, predominantly displayed so that their boss can read it, since project managers are often asked to come up with "creative solutions". Knowing what the classic mistakes are, in advance, helps one to avoid them.

Project Success Basics

Large sums of money are spent along with many man-hours to establish frameworks and processes that will give a software project a fighting chance of success.

However, there are fundamental (and less costly) measures that should be put into place first, as recommended by the Standish Reports:

The project manager must have the full backing of executive management. This requires a qualified executive decision (selecting the right project manager) by someone who knows the nature and abilities of their project manager, and a continued and close interaction with them during the project.

The business users must be involved during the entire project. Whether or not they give clear cut specifications, change their minds, etc., a sure way to hinder the success of a project is to lose touch with the people who came to you for assistance in the first place.

Specifications are clear-cut and achievable. At times it is all too easy to push fuzzy and unreasonable specifications over to the development staff, and then watch them fumble. Management must insist that the requirements are clear, and reasonable.

Responsibility and accountability: Each team member must have a clear understanding of their roles and duties. Perhaps most importantly, the project manager must be given the authority to manage (see the first item in our list), since they will certainly get the blame if things go wrong. The project manager cannot be someone who just keeps a project diary or maintains the schedule.

These are just a few of the fundamental principals that must be followed in all projects, regardless of the management software and tools that are used.

The Birth of Agile Development

Up until around 1980 or so, many software projects were carried out by what is called the "waterfall" approach: painstaking effort spent eliciting user requirements, publishing design documents, and coding to the specification -- often using COBOL.

The problem was that it was a rather slow process: no one can ever rattle off all of their requirements, accurately, and by the time the code was written the requirements may have genuinely changed. Using a language such as COBOL tends to make team write many lines of code.

In the late 1970's and into the 1980's, there was a movement of "fourth generation languages". The most notable of course was NOMAD2, and to a lesser degree FOCUS. NOMAD2 had a highly sophisticated DBMS, high level programming language, extremely rich set of functions, and the best report writing language ever seen. Corporations such as Bank of America and Chevron were early adopters of NOMAD2 and each had millions of lines of code in it.

This enabled developers to take the specifications and build a working prototype rather quickly, which in turn presented something visible and tangible to the user as opposed to having to rely on written documents and sketches of screen layouts. This process in turn fed back into a refinement of the specifications, and a better deliverable done more quickly than if previous methods had been used.

Perhaps without knowing it, the "agile" methodology had been born (this will, I know, contradict the belief that it was born at a ski lodge in Utah). 4GLs, as they were known, were used extensively in the '80s, but their use waned with the explosion of client/server technology (thus moving away from mainframes), Windows, event driven programming, and the rise of SQL as the de facto query language (which has yet to equal 25% of the abilities found in NOMAD2).

Like many worthy software products, most 4GLs did not make the transition to the Windows platform and we ended up with lots of C, C++, and VB, along with new DBMSs, most notably SQL Server and Oracle. In some ways we went back to 3GL coding, but with much more complexity, and so we rewound and the search for a "better way" got fresh legs.

Too often one can become part of a religious war of waterfall vs. agile, rather than focus on what practices will work best for the project and the team available. These thoughts will be explored more in future articles.

Project Manager Selection

Many times the success of a project reflects favorably on senior management, while the failure of the same project will be blamed on the project manager. Without question the role of project manager is critical, but so is the quality of senior management's decision on which manager is being matched to a particular project and development team.

Equally important is whether a project manager has been given the authority as well as the responsibility of managing a project. If a manager has little or no authority to enforce coding standards, source control, unit testing, or to resist scope creep foisted upon him by users or (even) senior management, then this manager can hardly be held accountable for failures in these areas.

Senior management must not only correctly select the right manager for a project and the associated team, they must make it clear that their choice of manager has their support, and the authority to run their own show. Selecting a manager that has never done at least moderately agile development may not be the best choice when managing developers who have done nothing else. But, selecting a manager that has done waterfall and agile may be a very good choice since the manager is in a position to educate the development team.

There are a number of key points for senior management to consider when assigning the manager. A project manager is not there just to take notes during meetings and send out updated status reports, or just add more detail to the project plan. A project manager is there, at least partly, to ensure that quality deliverables that meet the business specifications are built, on time. Many times this must be done while harmonizing with developers who are temperamental, for whatever reasons.

Clearly, a large burden is put upon senior management to select the right manager for the project and personnel.

When Is Software Like A Fence?

When is a software project like a fence?

Building a fence a time or two gives one a sense for how much time a fencing project will take. Removing the old fencing, old posts (and concrete), and cleaning up the work area for the new fence are all part of the project. (And so is hauling it away, but somehow I've failed to negotiate that point with tradesmen a time or two!). Computing how much and what types of wood one needs, how much concrete, and how much time is needed for each fence section are relatively straight-forward.

Things that will affect a "linear" computation of cost and time will arise, such as terrain, difficulty removing concrete for the old posts, weather, permits, and so on. However, after doing a few fences one can become pretty accurate in estimating the cost and duration of a fence project.

A few things that really help this are: the fence is tangible; one can see the terrain; one pretty much knows what the owner wants; it is unlikely the fence requirements will change drastically half-way through.

But that is the art of software project management: reducing concepts and intangibles into "real" things that can be visualized, estimated, and built. Seeing the unforeseen. Letting the users know that changes to certain specifications are like tearing down a fence and starting over. That changing specs early on (before the concrete dries around the fence posts) are easier rather than doing them later. That changes are doable, but changes have two side effects: time and money.

Just as building a fence requires a progression of tasks (e.g., one cannot put up the fencing until the posts are in place and the concrete is dry), so does software development. Just as there is a point where adding people to a fencing project will have no positive effect, so it is with software teams. Just as one can look at the amount of fence standing and conclude what percentage of the project is done, so must a manager know how much of the project's tasks are complete so he knows where the project stands.

While a software project usually has many more complexities than a fence project, at times it is helpful to step back and try to see software projects from a more practical viewpoint and less as a morass of out of control details. A manager must be able to translate intangibles into tangibles.

Inauguration

For this inaugural post I thought it appropriate to state what I hope to achieve here.

Whether you have been at the helm of project management or directing technology efforts, have been at the "receiving end" of such, or perhaps you are a technician caught in the middle, you know the effort and frustration that can accompany software development.

I have been in all of these places. I've been part of failures and successes, fun companies and miserable, profitable and not so much. I have worked with highly skilled people and with those who should not be responsible for managing a lemonade stand.

What I have learned is what we all do: people (at least the ones you want on your team) like to be part of successes and to feel as though they have achieved something with their time. Your definition of success may differ from mine, but you know when you've had one. It usually involves staying within schedule, and budget, and delivering quality. Some fun along the way and a bonus is even better!

So, this blog will attempt to deliver some practical advice and stir your thoughts towards more success in software project management -- whether you are a director, a project manager, a developer, or a user.