“Failure to deliver within our estimate is an estimating failure, not a production failure.” — Tom DeMarco, “Why Does Software Cost So Much?”

Software development is a process of discovery, so project cost, schedule, scope and quality must be estimated — development is not manufacturing. Requirements analysis and design are part of the product development life cycle, thus most of the work in determining what to do (scope) and how to do it come after the project has started.

The problem is that projects commit to unrealistic schedule and budget expectations, due to little or no information about the size and scope or productivity. Yet the business reality is that projects must be estimated early in the life cycle to support business goals and strategic planning. What ends up happening is that project stakeholders agree to unrealistic commitments, because there is a false sense of precision in single value cost and schedule projects.

These challenges can be overcome with a transparent and collaborative estimation process. This requires a well-defined, repeatable estimation process, as well as a way to share and solicit information upon which to base the estimate.

Every stakeholder has good intentions. Team members and project managers want to step up and deliver upon expectations of senior management. Senior management wants to achieve business goals and reduce risk. Customers have a vested interest in supporting the project team and removing obstacles. However, each stakeholder comes to the project with different perspectives, based upon different sources and interpretations of information about the project, coupled with personal and political objectives.

Engaging Stakeholders

Engaging stakeholders in the estimation process increases the rigor of initial and subsequent estimates, because information upon which the estimate is based and its sources is open and verifiable. Presenting a recommended estimate, along with a thorough analysis of alternative estimates that show a range of potential outcomes, helps project managers anticipate stakeholders’ reactions to the project. Negotiations are focused on practical solutions that lead to realistic commitments, support data-driven decision-making, and keep stakeholders engaged as the project progresses.

Estimation is not a process to be performed in isolation. It is a key input to project planning and business development strategy; however, it is important that the entire development life cycle is supported by data collection and analysis. As estimates and plans are updated throughout the project schedule, especially actual product, schedule, and effort metrics used in variance analysis, a rich history of project performance can be maintained as the basis of realistic future estimates. A sound and repeatable estimation process depends upon metrics collection and analysis.

The early stage of project concept definition and estimation is a particularly important stage to engage stakeholders, because this is when they have the greatest influence and opportunity to effect decisions. What is reasonable? It is difficult to truly see whether an estimate is realistic until it is validated against history and weighed against other solution alternatives. Creating an early Rough Order of Magnitude (ROM) estimate based on project scope and the most constraining factors (effort, cost, staff, or time) lets stakeholders quickly assess a project’s worth with minimal resources. For example, a cumulative cost curve for the desired project goals, compared to a typical similar project from history, shows when expectations need to be re-evaluated:

Trend lines are another way to provide a visual means of seeing how important project metrics stack up against typical values for similar projects of the same size. How does the project schedule compare? Values inside plus or minus one standard deviation are within the realm of possibility. Values outside this range approach the Impossible Zone.

Shown in Figure 3 as the Balanced Risk Solution (circle), we see that the Current Solution (diamond) is aggressive on effort, that is it predicts less effort than the historical average for projects the same size. The statistical regions have been translated into a shaded region above the average (moderately risky), white around the average trend line (typical), and lighter shading below the average (moderately risky). Thus, the Current estimate effort is Risky.

A detailed comparison between these solutions helps identify the driving forces, say staff size or scope that can be adjusted to bring the estimate in line with known capabilities and project goals. Detailed analysis is enhanced by using a Risk Comparison Chart that lists key project metrics on the left, along with values calculated for both the Current and Balanced Risk solutions. The risky values are all related to staff and effort. The estimate’s planned average staff of 7 FTEs (Full Time Equivalents) is less than one third of the typical project. Stakeholders can clearly see the difference, and are equipped to negotiate potential remedies; either reducing scope, extending the time line, or applying more resources.

Here is a sample Risk Comparison Chart, with current estimate’s risk assessed relative to the Balanced solution (left is Conservative, middle is Typical, right is Risky):

More often than not project business targets are out of range. When the estimators do not have a repeatable estimation process based upon history, they have no grounds to refute unrealistic expectations. Nor are they able to engage diverse stakeholders from multiple disciplines to take advantage of their knowledge or ability to effect change. A metrics-based estimation process, however, allows quick and easy “what-if” analysis to explore the potential outcomes of alternative ways to run the project. Calculating the cost and risk for shorter or longer delivery times, fewer features, multiple releases, or larger teams fosters communication and negotiation among stakeholders. This process provides a framework for zeroing-in on the best estimate.

Building Blocks

Engaging stakeholders in any project management process requires planning, and a structure for sharing the right information with the right people at the right time. The basic building blocks for this structure are:

• Organization Breakdown Structure (OBS)
• Roles and Responsibilities
• Access Permissions
• Project Data

Similar to a Work Breakdown Structure (WBS), the OBS defines the organization’s hierarchy for managing projects. Whether the defining split is by department, location, cost center, or other category, both projects and stakeholders may be assigned to an OBS node. For example the root node may have three children nodes; one by customer, and two by division. The structure could be broken down further by application type.

Defining clear roles and responsibilities helps stakeholders understand how they interact with the project team and one another, what activities to perform, and where they can make a contribution to the success of the project. Only a handful of roles need to be created. A simple way to define roles is to replicate levels of decision-making authority, adding functional expertise. Here are a few examples:

• Executive – view only privilege across all nodes
• Portfolio Manager – view only privileges for specified high-level nodes
• Project Manager – primary responsibility; create projects and full access privileges
• Contributor – update privileges only
• Stakeholder – view only privileges; limited project and/or node access

The benefit of defining process roles is that they provide a low maintenance way to grant access to project data without having to keep up with individual stakeholder’s changing faces and positions across the organization. OBS nodes, roles, permissions, and stakeholder “users” work together to not only grant access to specific projects, but also to specify the extent to which data view and update authority is available. There are four key links.

1. Projects are assigned to OBS nodes. Granting access to nodes above a particular node allows automatic roll-up of project data to support portfolio management and PMO functions.
2. Stakeholders are assigned to OBS nodes, ensuring that the right people have access to the right projects.
3. Stakeholders are assigned roles, such as Contributor.
4. Permissions are assigned to roles. Some stakeholders may require full access privileges to project data, such as the project manager and key technical staff; others may contribute to the project by providing detailed sizing data, or performing what-if analysis. Senior managers and customers may be limited to view only access, so they remain informed and engaged, but cannot modify project records.

Here is a conceptual architecture of shareholder project information access rights:

Because people wear many hats within an organization and may possess greater authority on different projects, stakeholders may be assigned multiple roles across multiple OBS nodes. For example, David is a Project Manager in the Aerospace Applications group within the Product Development Division. Since Dave is the software-sizing expert, he is also assigned as Contributor in the other Product Division groups. Here are two ways to implement this requirement: a) assign David as Contributor for each sibling OBS node, or b) assign David as Contributor to the parent OBS node. Option b only works if each project’s access is set to grant access to OBS nodes higher in the structure.

Final Thoughts

Process improvement initiatives are often underfunded, because the return on investment is difficult to demonstrate without data. Gathering a handful of metrics for completed projects and establishing a transparent and collaborative estimation process can result in huge savings simply by avoiding disaster. Taking on a risky project is a legitimate business decision under the right circumstances. However, a repeatable and collaborative estimation process equips executives to make those business decisions.