Introduction

Ever since software development projects have been around, people have been coming up with ways to help ensure they come out well. Unfortunately, history shows us that there is no process, methodology, or toolset that can guarantee project success. But there are some practical techniques, many of them non-technical, that can dramatically improve a project’s chances.

In this, and in the next couple of postings of Business Analyst Times, I will lay out techniques based on observations from my own personal experience that I know can reliably produce excellent results. In combination, they can result in what is experienced as a “perfect project”. I present from more of a project management perspective rather than pure BA one, because my experience has been that management activities and decisions tend to impact projects, for good or ill, more than technical ones. The ideas that follow are in approximate order of importance. They are necessarily quite brief, and each one is expanded in future postings. 

1. Keep the project as small as possible. A project’s size is inversely proportional to its chance of success. As people are added to a project, the potential number of interactions increases pretty much exponentially, and things fall through the cracks, often catastrophically.

2. Carefully select a leadership team comprised of a project manager and key business and systems analysts. They must be highly qualified technically and must work together well as a team.

3. Create a partnership relationship with the customer. To improve the project’s chances of going smoothly, these two organizations need to work in concert, where mutual trust, joint responsibility, transparency, and good will are operative.

4. Limit formal processes and documentation to a minimum. “Big Process”, as exemplified by CMM/CMM and the IEEE standards can get in the way of a small sized project with high quality, motivated people.

5. Work intuitively. Operate at least partially in the mode exemplified by the Agile Methodology. By being highly flexible and willing to change as users are exposed to the emerging system, the probability of system acceptance is greatly increased.

Anyone who has been around a while knows that the conditions for achieving the perfect project are not commonly present. But, if they do exist where you now are, or you can influence things to cause them to exist, then enjoy your perfect project.

Keep Project Size Small

My experience has been that project size, in terms of the number of people working on that project, is inversely proportional to its chance of success. I have been around several projects that had 100+ staff. While none of them outright failed, none of them came out particularly well. In one instance, a literal handful of people (myself included) redid one of those large systems in a year of intense work, and turned a mediocre system with poor performance characteristics into a roaring success.

Why do large projects have problems? In a nutshell, the active principle is project communications. As people are added to a project, the potential number of interactions increases pretty much exponentially. The result is that important communications don’t always get to all necessary recipients, and things fall through the cracks. Mistakes are made, and they can prove to be disastrous. People feel isolated, morale tends to be poor, and turnover is high. Big projects try to mitigate this by requiring huge amounts of formal documentation and by holding many, many meetings. The sheer mass of material makes it nearly impossible for individuals to read everything they need to read to stay up to speed on everything that might affect them. It also becomes almost impossible for any one individual to comprehend the full documentation set as a whole, meaning that there may be no one individual who understands the entire project.

Any project that has more people than can fit around a large conference table is going to experience degraded performance due to communications issues. Conversely, with a small team, any communications issues can be addressed face-to-face and be observed by the entire project team. Much can be done on an informal basis that would otherwise require formal process and documentation. For instance, the two persons responsible for both ends of an interface can sit down at a whiteboard and work out the interface, and then, instead of creating a formal Interface Control Document, they just send an email summarizing the design. When it comes time to test the interface, both parties can be present and can troubleshoot and fix any problems on the spot. I know this works, because I have done it.
 
A small, closely knit team of sharp people can work miracles. I have been lucky enough to have worked a few myself. I claim that with such a team, working informally and without undue process and documentation overhead, I can build a given system faster, with better quality, and with better user acceptance than can be done by your average 100-person team, working under what is considered best practice processes.

Some projects are just too big functionally to do them with a single small team. This is especially true if hardware and communications must be procured and integrated, facilities must be built, and national security data is involved. But it may be possible to cleanly partition the problem into a set of functions that can then be implemented using a set of closely cooperating small teams, with a top-level team comprised primarily of team leads. Each team then operates independently on its functional area, and the top-level team ensures that cross team issues such as interfaces get handled efficiently and effectively.

© Copyright John L. Dean, 2008.

Look for Part 2 of Road to the Perfect Project in the next Business Analyst Times

---

John L. Dean is an IT professional whose long and broad experience base gives him an unusual perspective on what does and does not work. He has 40 years experience, mostly in government IT contracting, including systems engineering, systems analysis, requirements analysis, systems architecture and design, programming, quality assurance, testing, IV&V, and system acquisition, equally split between technical and management. He has worked on both the contractor and government sides of the fence, has been an employee of large (IBM, CSC, Booz-Allen, MITRE, ACS) as well as very small companies, and more recently has worked as an independent consultant. John has a Masters degree in Operations Research from Clemson University. He can be contacted at

[email protected].

Building The Right Thing

One problem with software development methods these days is that there are a lot of different ideas on the right way to build things, but we don’t have too much guidance on how to make sure we are building the right things. There is plenty of advice on the best techniques to develop quality software, but all of this guidance is based on the assumption that the team already knows what they are supposed to be building. When it comes to how to find that out, just about every methodology has the customer/stakeholder/product owner prioritize the features/use cases/user stories.

Great, but do our stakeholders always know a sure fire way to properly define what is the most important aspects of a product or system. Do they always have an objective understanding of whether the product or service should be created or updated in the first place? All too often, stakeholders don’t have a clear idea of how to determine if they are asking for the right thing, and the project team doesn’t necessarily help them.

So what does it mean to build the “right thing”? Well, one way to look at it is to understand:

• What projects should the organization undertake? 
• What features should be provided for those products or services? 
• What order should features be delivered?

So how do project teams “do the right thing”? It comes down to the project team, including the stakeholders, working together to understand the organization’s definition of value, applying that definition to determine the value delivered by their projects, determining how the features contribute to the project’s value delivery, and prioritizing the features accordingly.

We’ll discuss each of those steps in turn. One thing to note that whenever I say project team, I include stakeholders in that grouping, and I use stakeholders interchangeably with customers, product owners, users, goal donors, and gold donors.

The Organization’s Definition of Value

Value is one of those words that, while easy to define, often means different things to different people, especially when used in the context of software development projects. The most appropriate dictionary based definition is: “relative worth, utility, or importance.” (http://www.merriam-webster.com/dictionary/values). When you consider this definition, it is easy to see why the definition of value will vary between different organizations. It just so happens that an organization’s strategy, as expressed by its strategic decision filters, provides a definition of value. Strategic decision filters basically provide simple rules to determine which activities create and support sustainable competitive advantage, and which activities detract from an organization’s maintaining its competitive advantage. Anything that creates and supports the organization’s sustainable competitive advantage inherently is valuable to the organization.

The Value Delivered by the Project

Once the project team understands what is valuable to an organization, they can establish a value model for the project, which provides the project team with a tool to repeatedly assess the value delivered by a project.

The value model has four key inputs:

• Purpose. A statement about what problem the project is trying to solve, or for those optimists out there, the job that the project is trying to get done.
• Considerations. All those aspects of the project that could impact the value produced by the project, but are either too difficult to quantify, or haven’t happened yet, such as risks, issues, assumptions, and constraints.
• Cost. The financial resources required to undertake the project, including such things as the people working on the project, hardware, and software.
• Benefits. The positive impact the project has on the organization. Benefits can be financial in nature, such as increased revenue or reduced costs; or non-financial, such as support for other initiatives, or improved customer satisfaction. It is a good practice for the project team to collaborate on the purpose of the project first and run that purpose through the organization’s strategic decision filters. If the project fits within those filters, the project team can then continue to understand the remaining inputs. If however, the purpose of the project does not pass the strategic decision filters, then work on the project should stop, as it will most likely not deliver any value to the organization. Of course, if the result of the effort to evaluate the project purpose against the strategic decision filters results in the question, “what strategic decision filters?” then the organization has some more fundamental work to do.

If the project is a strategic fit, the project team then collaboratively identifies the considerations, costs, and benefits of the project and crafts a model to determine the value delivered by a project. This model should be built in such a way that it can be quickly updated and analyzed throughout the life of the project as considerations change, costs are better understood, and the benefits produced become clearer. The advantage of this approach over the typical practice of developing a business case to justify the project and then never reviewing it again, is that the project team is able to determine if the project is on track to deliver the expected value, or if conditions have changed such that the project no longer makes sense to continue.

Feature Contribution to Value

Once the project team has a grasp on how the project adds value to the organization, they can start analyzing how the various features under consideration contribute to the overall project value delivery. This can be difficult because the size of feature that delivers discernable project value is often different than the level at which the project team is comfortable fully defining features. A solution to that problem is to group finely grained features into the smallest grouping that delivers value to the stakeholder. Mark Denne and Dr. Jane Cleland-Huang introduced this concept and called them Minimal Marketable Features (MMF) in their book Software By Numbers (http://www.softwarebynumbers.org/default.htm).

 Project teams can organize their features into MMF and then, through an understanding of the relative value of those MMF’s to the overall project, prioritize the features delivered by terms of relative value contributed to the project. This approach is especially effective when the project team is following an iterative approach to development, when subsets of the overall feature set included in a project are delivered on a regular basis. Ideally, project teams will find themselves in a situation where they are able to identify a financial value delivered by a feature, but this is the exception rather than the rule. More often than not, project teams have to express the value in relative terms compared to other features included in the project. Regardless of the measure used, whether it be hard dollars, or a unit of less relative weighting, the key is for project teams to have some understanding, objective or subjective, of the value each feature contributes to the overall project and use that value as the basis for prioritization decisions.

Really Analyzing the Business

What I have just described is business analysis at its finest. It goes beyond simply “gathering” requirements to truly developing an understanding of the business, the problem that needs to be solved, and the benefits of the solution to the overall organization. This approach requires a great deal of collaboration between all involved in a project, especially business analysts, who should have the appropriate skill sets to facilitate the creation and revision of the value model, and the application of that definition of value to the features included in the project. A business analyst who has these skill sets is truly setting themselves up as an invaluable person to their organization.

---

Kent McDonald

is a Business Systems Coach with Knowledge Bridge Partners and Partner in Accelinnova, http://www.knowledgebridgepartners.com. He has more than a decade of experience guiding successful projects and designing business solutions in a variety of industries including financial services, health insurance, performance marketing, human services, non profit, and automotive. His background includes delivering data-intensive and web-enabled application development projects that provide outstanding business value. He has coached client staff to help teams reach project goals more productively and effectively. Kent is a speaker, writer, and coach on project leadership, business analysis, and delivering business value through projects. He can be reached at [email protected]