There are many ways to regain control on projects that are going wrong. The classic way starts with investigation, usually in the form of a project audit. However, some mandates or company cultures call for a more direct and participative approach. In the later, the consultant has to perform investigation and implementation at the same time. This approach can also be more cost-effective than formal auditing if we suspect that the problems are not too complex (this is really a judgment call).

One of the typical symptoms of projects going wrong is that the team cannot deliver as planned with the desired quality, at least not without putting more effort (additional resources, overtime) than planned. Managers, clients, and team members blame processes, lack of skills, inaccurate requirements, unexpected changes... and each other. But in truth no one knows exactly why the projects are heading toward failure.

Replanning the projects can help pinpoint the problems. The consultant acts as a project manager facilitator to elicit real effort forecast directly from team members. Note that, in the first phase of replanning, we do not set any hard deadline for projects (this will be added later). Indeed one of the pitfalls of project planning is to plan according to a predetermined deadline instead of according to effort needed to complete the project.

Replanning requires one or more meetings with the whole project team (assuming the team size permits it) to redo the work breakdown structure (WBS) starting from requirements ("features" to be delivered, also called "user stories" in agile methods such as Scrum).

Second, the consultant together with the team estimates the team velocity, or production capacity. The velocity is calculated independently for each activity involved in the project, such as analysis, architecture, development, testing, deployment, and so on. The key here is to determine the real velocity, taking into account all kinds of interruptions, vacation, sick leave, emergencies, maintenance tasks, contribution to other projects, and so on. The result will likely be very different from the velocity used for the initial project plan (which is often 5 days per week per person, an absurdity knowing that focus on the project rarely exceeds 80% and is more likely around 70%).

Combining our new WBS with the newly calculated velocity, we can plan the project. The level of detail depends on the situation. The current iteration should be planned in detail (unit = one hour for example, WBS element is task), while the rest should be more coarse (unit = one day for example, WBS element is feature or scenario).

The third step consists in checking where the real deadline stands compared to the original (read: ideal) deadline. Often the original deadline is a hard deadline; it cannot be moved because it has been promised to the client. Therefore, the project manager has to negotiate with managers to allocate more resources to the project or negotiate an agreement with the client. Either way, it would be ridiculous to ignore that the real effort doesn't fit with the hard deadline. Poor project management implies "working the numbers" until it fits with the original deadline, making all kinds of unrealistically optimistic assumptions along the way (at some point the s**t will hit the fan).

Until now we have essentially worked to create visibility. We made stakeholders aware of the real effort to complete the projects, but we didn't solve any root problems. With our new numbers for WBS elements and velocity, we can derive some simple yet useful statistics: how is the effort distributed among WBS elements, roles, persons, iterations, and so on? These numbers will likely raise a few red flags that will help identify problems.

Numbers can be examined from multiple perspectives. For example, which activities consume an inordinate amount of effort, and why?

• Analysis: requirements are inaccurate.
• Architecture and design: there are serious technological risks such as new technologies, tools and frameworks.
• Development: same as architecture, plus lots of out-of-project interventions.
• Testing: fuzzy requirements or lack of unit testing during development tends to postpone problems until integration testing.
• Deployment: transition from development to test and from test to production environment is tedious and error-prone.

Consequently, in parallel to executing the project, we can also work on the root causes of our problems so that they do not plague future projects and later iterations.

For sure, this approach is not as systematic as an audit, but it offers a quick fix to simple problems that plague the projects, and provides a good starting point to improve more intricate parts of the software development process. It also has the great advantage of involving the team from day one in a coaching mode.

You want to convey some important information for decision making, and...

• Verbal communication is not enough. It should be written.
• Readers are time-starved. It should be concise and it should address a specific issue.
• It has a few weeks to a few months lifespan and can be printed. An in-text email is not appropriate and is not meant for keeping. It should be a well-formatted, self-contained document.
• You don't have time (or it's not cost-effective) to conduct a full scale analysis. It should be brief and to the point, based on educated guesses rather than on research.

It's a memo.

From Memoranda Writing, by J.P. Dobel, R. F. Elmore, and L. Werner:

A memorandum is a relatively short, written document. Memos address specific people or groups for the purpose of recording an agreement, transmitting information, making a case, or enabling action. Brevity is essential because most decision makers have little time and must assimilate the contents of your memo quickly. Long memos don't get read.
Think of a memo as a precision tool. Tools may be beautiful things in themselves, but we measure their value by how well they perform a task. In practical terms, every aspect of a memo - its prose style, organization, appearance on the page and content - should have a direct, relationship to its purpose. Long flowery introductions, technical jargon, casual chit-chat, or showy vocabulary all distract from a memo's essential purpose: to inform or to enable action.

It was supposed to be a 5 pages long document. I finished it last weekend, and it is 15 pages long. I just couldn't make it any shorter without omitting critical sections.

Here it is: Practical Guide to Auditing the Software Development Process

The purpose of this document is to summarize the process for auditing software development (SD) practices. Although business and academic sources extensively cover both auditing and SD processes, there is surprisingly little information about audit applied to SD. This document briefly describes the SD audit process based on publicly available information as well as personal experience in SD auditing and in IT project management.

The document provides a brief overview of the phases of SD auditing:

1. Initiating the audit
2. Analyzing the organization, focusing on the role of SD in the organization
3. Evaluating the SD process, with emphasis on the 360 degrees assessment including clients/users, the team, management, and direct observations by the auditor, as well as the sources of information such as documentation, surveys, and interviews
4. Evaluating tools and technologies
5. Testing evaluation results
6. Reporting audit results, which includes how to convey a high-impact recommendation based on the comparison of realistic alternatives
7. Following up, describing how to make sure that recommended changes are implemented after the auditor leaves the client's premises

As you can see, it is quite comprehensive. I expect this document to be a perpetual work in progress, and your comments are welcome, of course.

When I was writing a document to summarize the software development (SD) audit process, I came across an interesting question: how is SD audit related to transition and change management? They are obviously related, but I couldn't put my finger on how they fit together. So here is an attempt at formalizing the relationship between SD audit, crisis, and transition management.

Although it is sometimes independent, the SD audit is often closely related to transition, change, and crisis management. The sequence is as follows:

1. Crisis: the organization faces SD problems that threaten its business objectives.
2. Audit: the organization performs an SD audit to identify the causes of the problems and to find solutions.
3. Transition and change: the organization implements the recommended solution. The transition can range from non-disruptive changes (a series of minor improvements), to specific changes (a small number of significant changes), to full-fledged transition (changes that deeply affect SD processes, structures, and possibly other business processes).

[EDIT 24 Nov 2008] A Practical Guide to Auditing the Software Development Process is now available.

At last I have some time to write about some interesting topics that require some research. I noticed that auditing the software development practices is vastly misunderstood. Some think it deals with accounting software whereas others think it's about programming guidelines. It is neither. It is a relatively new discipline, but I suspect that many IT managers, consultants, and project managers have already been wrestling with it. I will use my experience, combined with some research, to help formalize the software development audit process. So expect a few more posts about this hot topic!

Let's start at the beginning.

The purpose of a software development (SD) audit is to assess SD practices in the target organization and to recommend improvements to help the organization achieve its business objectives. Although the scope of an SD audit can vary, it typically encompasses SD processes, organizational structure, tools and technologies. In essence, the goal of the SD audit is to optimize SD's effectiveness and efficiency.

Note that an SD audit is not an IT audit. Although there is some overlap, the IT audit deals primarily with IT operations.

[EDIT 24 Nov 2008] A Practical Guide to Auditing the Software Development Process is now available.