Ivar Jacobson's Blog

In a prior blog entry I noted the traditional approach to funding new development efforts:

1. the business gets an idea and writes a few sentences of description,
2. IT tries to figure out what the business really meant and comes up with an estimate based on their best guess, and
3. this amount gets locked in as a "committed" estimate to which IT is held accountable. 

The only thing that should be committed is the people who think this is a sane approach to funding projects.

A better model works like this:

• The business identifies a set of desired business outcomes that they would like to achieve, along with the net present value of achieving those desired outcomes.
• Based on this value, the business decides how much it is willing to spend to achieve those desired outcomes.  Usually this is based on the required rate of return of investments in the business.  This amount establishes an upper limit on the project that could deliver those outcomes.
• The IT planning process then focuses on determining whether the desired outcomes can be achieved within the constraints established by the business planning process.  If they cannot, further funding for the project is stopped and more worthy projects are funded.  Several alternative approaches may be tried and rejected, and deciding project feasibility may require some prototyping and evaluation to determine viability.

This is how research and development funding works and, let's face it, software development has a lot in common with R&D: both deal with a lot of unknowns at the start of a project, so much so that it is usually not possible to precisely define the exact work that will be needed to achieve a particular end.  Both R&D and software are essentially exploratory: at the beginning of the effort the exact result is not known with a high degree of assurance so we have to evolve toward a solution.  The current funding model's assumptions that the solution is easily definable and therefore should be easy to estimate just doesn't work for most new software development efforts.

The Software Development Process Challenge

*The first post in this series can be read here

Before I describe the deck of cards, I’d like to set the stage for using the cards. We can view software development from three time-scales (see Figure 1). Successful software development process is in essence, being able to coordinate the three time-scales effectively.

• The broadest time scale covers from the beginning to the end of a software development cycle which is marked by several key business decision making milestones. This is of great interest to stakeholders and decision makers on whether development can proceed or whether the software is suitable for release.
• The next time scale breaks the lifecycle into time-periods – months, or weeks, or what is known as an iteration. It is a fixed time-box where a number of target objectives are to be met by a development team. If there are multiple teams, then each team would be assigned their specific set of objectives. This is where team leaders operate.
• The lowest time scale is what a team member does. The work done here can be in terms of hours or days depending on the complexity of the work.

Figure 1:The Three Perspectives to Software Development.

A major problem I see in many development organizations is the serious disconnect between the three levels. The objectives set at the higher level do not easily translate to work at lower levels. Lower levels are unable to see their contribution to higher level objectives. There is a  miscommunication between the levels, and poor coordination within the same level, which leads to blockages which should not even happen. We need to solve this.

Most project management approaches address risk in a fairly superficial way: risk mitigation is viewed as an important activity, but one that is largely a distraction from the main effort of the project. Risks are identified at the start of the project, they are usually assiged to someone to address the risks, but these risk-mitigation activities are largely viewed as things that take away from the project work. In practice the risks are only identified once and then they are largely forgotten in the large amount of work to be done.

On a traditional project, change is viewed as a bad thing, and great efforts are undertaken to prevent it. Change disrupts the original plan, and it is the plan (and not value delivery) that is sacrosanct on a Traditional project.

Similarly, change must be embraced. Change results from new information, from feedback that something in the original plan will not result in the desired end result. Change is something that will occur as people get new information, but change is a good thing: it means convergence on the right solution. Read the rest of this entry »

Over the last few days a number of people have asked me the same question: “How can we get more accurate requirements?” While I agree it is not nice to answer a question with a question, in this case you might bend etiquette a bit because in reality this question can be hard to answer. For example, why is it necessary and which problem does it solve? Or, what exactly do you mean with accurate?  And do you have accurate requirements and you want more of those? And in that case, more than what? Or do you have inaccurate requirements which you want to become more accurate? And if so, how much more?

You might say: “Hey, that’s just playing with words”. Well, that’s right and so is writing and communicating requirements. In order to get accurate requirements you need a number of things. However, an often overlooked element to writing accurate requirements is understanding the structure of language and how language is perceived. Read the rest of this entry »

Each iteration is unique. It involves undertaking a unique set of activities to produce a unique version of the product that objectively demonstrates that the iteration objectives have been met.

Because of this uniqueness, each iteration requires its own iteration plan. The iteration plan contains the details of all the activities that the team is required to do to meet the iteration objectives. The amount and style of activity-level planning required for a project is dependent on many factors including the project risk, team size, experience levels, and the manager’s own preferred management style.

For some projects, an informal plan describing the goals to be achieved and listing the tasks to be undertaken is sufficient; you can leave the scheduling and allocation of the activities to the development team. Other projects require more comprehensive plans that describe the activities and their allocation in greater detail to work out the dependencies between the tasks to be performed by the various team members. Read the rest of this entry »

Traditional project management approaches focus on planning in detail, assigning the resulting tasks to people and then tracking "progress" as measured by completed tasks. The problem with measuring progress this way is that completing a task, while important, is hard to correlate with progress against the overall goal - just because you've completed 20% of the tasks does not mean that you're 20% done - and for tasks that take a long time to complete the self-reported estimates of "percent complete" is often merely "wishful thinking".

My preference is to measure progress in a concrete and measurable way - in the form of tested scenarios, following an iterative project management approach.  In other words, planning works iteration by iteration, with each iteration developing and testing one or more scenarios.  At the end of each iteration, you have a set of developed and tested scenarios, making progress easier to measure: knowing that you've developed and tested 20 out of 100 scenarios is a lot more meaningful than knowing that you've completed 20% of the tasks - especially if those tasks are focused on creating documentation rather than running and tested code.  Scenarios correlate nicely with business value - each scenario should be useful to at least some subset of the stakeholders.  In my view, only when you've successfully tested a scenario can you claim to have "earned value".

There are a number of studies that cite poor performance of software projects - The Standish Group being the authors of one of the more often cited, their Chaos Report (and old version from 1995 is posted here, and although the data is old the conclusions are not dramatically changed).  The gist of these studies is that the majority of projects (as high as 70%) fail when measured against original schedule, budget, and expected features. I would be the last to argue the general conclusion: that it is very hard to manage a project to success. 

Most projects lack clear direction and purpose, and many are rife with disagreements about what success looks like.  There is, however, something in the assumptions behind these studies that rings hollow: that the initial schedule, budget and expectations for projects is a reliable milepost against which to measure. Most projects are vaguely conceived at best - they often lack a clear understanding of why they should exist and what problems they need to solve.  At their initiation they are usually poorly scoped and vaguely purposed, and the funding associated with them is often assigned based on an  allocation of an arbitrarily assigned budget.  Their schedules, at least those produced at the start of the project, are largely speculative endeavors, a mixture of gut and guesswork, that bears little basis in reality.  Measuring project performance against the initial schedule, scope and budget is of little value except to illustrate the point that there is a large disconnect between the expectations of business sponsors and the ability of teams to deliver against those expectations.  There are, to be sure, rampant problems with performance, but there are also widespread woes of expectations that are just as important to address.

Where should we start?  The first place is probably with project funding and measurement. The real thing of importance to measure is whether the project produced (or exceeded) the business value  expected of it.  If a delay in the project caused a market window of opportunity to be missed, that is significant, but it is the decline in value delivered that needs to be measured, not a schedule variance that cannot be correlated with economic activity.  Forcing a focus on business value produced would also put the right attention on the role of the business in following-through on their assertions of the value that will accrue from having the solution.  Requesting projects based on business needs has an opportunity cost - choosing one project over another should affect the value delivered to shareholders - and accountability for assertions by the line of business is just as important as accountability for project delivery.

If we shift our attention to value delivered rather than meeting schedule and budget, we may free the development team to find better ways to deliver the value, which may or may not include the initial set of features envisioned by the business sponsor.  Initial feature lists are usually vaguely conceived and don't provide a very good target for delivery.  Work is usually required to ascertain the real needs from this initial list of "features", some of which contribute to satisfying real needs but many of which are simply good initial starting points for discussion about real needs.  It may very well take longer than expected to solve the real problems (it usually does, as we all tend to be more optimistic than we should about how long things will take).

The problem is that most teams are set up to fail from the start.  By measuring them against budgets and schedules based on arbitrary assumptions and often a poor understanding of the real business value that needs to be produced, we find them constantly struggling against a plan that cannot possibly succeed.   Measuring against initial schedule, budget and expected features is not merely meaningless, it's actually part of the problem.  We need to shift our focus to better articulating problems to be solved and needs to be satisfied, and measuring business value produced.  Once we start to do that, we can focus on the plans and milestones needed to ensure the delivery of business value.