Chapter 4. Estimation

“There is no such thing as absolute value in this world. You can only estimate what a thing is worth to you.”

Charles Dudley Warner

“For me, every day is a new thing. I approach each project with a new insecurity, almost like the first project I ever did. And I get the sweats. I go in and start working, I’m not sure where I’m going. If I knew where I was going I wouldn’t do it.”

Frank Gehry

“It’s a simple approach. Sustainable architecture looks to the future by looking at the past.”

Stephen Gist

Have you ever had anyone stop by and ask, “I have an idea for a project; it looks a bit like this and has these high-level features. What will it cost?” Your mind begins to whir as you think about what this might entail. You begin asking questions for clarification. You begin considering where, when, and how this project will get used. You try to think of other projects that you have encountered that may be similar as you try to come up with a reasonable number. You begin thinking, “Wow, this is a cool project.” Alternatively, “Am I going to be held to this number?”

Welcome to the world of estimation.

Long before a single line of code on a project is ever written, the business and senior technology will have been working closely together to secure the appropriate finances necessary to fund projects and keep the pipeline of revenue growth or cost savings alive and well.

The architect is one of the chief links between the business world and technology. Your ability to hear what the business wants, translate it into a high-level concept, align it with the strategic needs of the business, and frame the concept for technology is a vital role.

This chapter unveils one of the essential skills needed by a software architect: the ability both to provide rough estimates and to provide the context to enable business case estimates to be produced.

Estimates Overview

Estimates are usually used by the business to help it obtain funding for a project. They enable the business to get a sense of

• What the cost of a project will be

• When the project can be delivered

• What risks are associated with the project

• What dependencies will potentially exist for the project

• What areas of the project are unknown

• What alternative approaches are possible

• What assumptions are being made about the project

Estimates come in all sizes and shapes, depending on what the needs of the business are. They will drive the associated costs, assumptions, risks, dependencies, and alternatives considered (see Figure 4.1).

Figure 4.1. Estimates drive projects based on the value propositions they reveal.

What Is the Purpose of the Estimate?

When someone seeks an estimate from you, one of the very first things to do is to determine what kind of estimate the person is looking for:

• Is this just a quick sizing effort so that the person can get the information immediately (a drive-by estimate)?

This type of estimate is best communicated verbally and not in an electronic format. It is usually used by the business to gauge what kind of investment is needed, to get some details about the nature of the development effort, and to determine if it is worthwhile diving into more detail. This kind of estimate may also be used to help the business pitch an idea to a product counsel.

I usually let my manager and the associated program manager know about the potential project and the high-level number that I gave.

This estimate has the potential to be off by an order of magnitude, up or down, given the lack of details that are typically exchanged and the amount of time spent on it (typically less than an hour, including the conversation with the requester).

• Is this a rough estimate on which the requester would like you to spend a day or two and to provide a little more detail (a rough order of magnitude estimate)?

This type of estimate normally takes on a little more formality. It is usually used by the business to gauge whether or not to move forward with a business case.

I usually work with the program manager to meet with the requester and develop an estimate. If necessary, we may include a handful of technology specialists if we are unsure about a particular area.

This type of estimate is usually formally communicated to the business and entered into an estimating repository along with any materials that were gathered and any high-level assumptions that went into the estimate. Again, I usually give my manager a heads-up about the potential project and the number that was delivered.

This estimate has the potential to be off by two or three times. Typically, for this type of estimate and for everyone included, try to spend less than eight hours.

• Is this something for which the requester wants a formal estimate—one that could be used to support a business case (a business case estimate)?

This type of estimate is normally very formal. It is usually used by the business to make the actual request for money associated with a business case. It is also used to determine the groups, skills, and staffing needed for the project.

I usually work with the program manager, the requester, and an estimating team to develop such an estimate.

This type of estimate is usually formally communicated to the business and entered into an estimating repository along with all materials created as part of the estimate. The estimate will be reviewed by the estimators and their associated executives before being formally communicated.

This estimate needs to be accurate within 10% and may take several weeks to produce.

With each of these types of estimates comes an increasing level of due diligence, documentation, and communication.

After the project has been approved and development has begun, there may be business case validation estimates that are requested to verify that the project is properly sized and scoped based on actual design details.

Is There an Established Project Context?

Ideally, by the time you are asked to help create an estimate for the business, you will already have been involved working with your business partners (refer to Chapter 1, “Partnership”), been involved in the discovery phase (refer to Chapter 2, “Discovery”), and had the opportunity to help formulate the product concept (refer to Chapter 3, “Conceptualization”).

If not, now is the time to deep-dive and learn everything you can about the product being proposed.

Without having a solid understanding of what the business is asking for, it is nearly impossible to develop an architectural approach and an estimate that make sense for the business.

What Is an Architectural Approach?

The goal from an architecture perspective for any of these project-estimating types is to develop an architectural approach. This will help set the boundaries to the estimate that is being produced and help frame what the project will potentially cost (see Figure 4.2).

Figure 4.2. An architectural approach can help drive and deliver consistent and reliable estimates for the business.

The key elements of an architectural approach include

• Describing background information about the project.

• Showing how the approach meets the desired business requirements.

• Delivering key diagrams that pictorially tell the story of what is being built. These may need to vary depending on the audience to whom you are delivering (for example, data center operations, product operations, technology development, or product development).

• Identifying risks, assumptions, issues, outstanding questions, dependencies.

• Identifying at least one way to implement the project. This may not be the final approach, but it will help ground the estimating process.

Once you have the project context and the architectural approach and have applied the appropriate estimating strategies and principles, you and the estimating team can work to produce solid estimates for the business.

Understanding the Estimating Process

As an architect, becoming familiar with the estimating process of your organization is critical. This process will bound nearly all of the activities that are expected of you and others involved in producing estimates for the business and will define what success means.

Estimating Pipeline

Whether defined explicitly or implicitly, every organization has some form of process for funding projects. Often, this pipeline looks like the chevrons shown in Figure 4.3.

Figure 4.3. Knowing the funding process will lead to better insights into when to engage the business and when best to influence a project’s direction.

As you are familiarizing yourself with the pipeline process, take the time to consider these questions:

• What is the pipeline of work that is coming your way?

• Are all the resources fully filled? Will you need resources with specific skills?

• Is there a cadence to your estimating—quarterly, ad hoc?

• What is the prioritization of estimating? For me, it is my highest priority. I often drop nearly everything for several weeks when estimating occurs.

• How much money is allocated to estimating (1% to 2% is normal)? Is it separately funded and tracked?

• What do you do if you have three or four large projects that need to be estimated at the same time?

• What if your business partners are not picking up projects (what should the ratio of estimated to funded projects be)?

• Where do small features fit in? Where does maintenance fit in?

• Who will review the estimates? Make sure your senior management is familiar with the estimates before they are generally released.

Types of Projects

The type of project you are estimating can have a significant impact on the information gathered within your architectural approach. Getting an early understanding of the project type can help you formulate what considerations need to be taken into account. Normally there are five main types of projects:

• Maintenance. This type of project is usually a keep-the-lights-on type of project. It has fixed funding on a year-to-year basis; it does not have a lot of resources assigned to it, but it has a lot of defects to fix and minor enhancements to develop. There usually is not a lot of architectural activity in this area. An example of this type of project is an established product that needs a certain level of funding to stay current with technology or to stay competitive in the marketplace.

• Migration. This type of project is usually the result of a burning platform—the project needs to be migrated off the current platform and onto a different one. This may be due to legacy operating systems, software, or hardware that is going out of support or that is extremely expensive to maintain due to opportunistic vendors. The challenge with this type of project is that it typically has fixed features, fixed resources, and a flexible date. Unfortunately, the extent of the features or their usage is usually not fully known, leading to surprises (read: budget busters) later on. Since there may not be new revenue associated with this type of project, the business’s interest in investing a lot will likely be limited. The challenge from an architectural perspective is determining how much change (reengineering) is warranted and helping to inform the business about the true cost of the migration (usually, not a popular message). An example of this type of project would be a move off of a mainframe.

• New/enhancement. This type of project is usually the result of market demand or potentially a new or adjacent market opportunity. These types of projects are usually fun and exciting, at least when they are starting out. The new product or new features may not be clearly defined, but a vision exists of where the product owners want to go. The challenge from an architecture perspective is that the direction the product owners want to go may be somewhere the organization has never been before. An example of this type of project would be building solutions to fill a gap in your overall product portfolio or to expand your portfolio into a new high-growth area.

• Integration. This type of project usually arises when another product is a market leader in a particular area and your business wants to integrate with it to enable easier sales of your product. This type of project can be challenging due to a lack of appropriate interfaces for what you want to accomplish and minimal leverage with the other product. An example of this type of project would be integrating into an order-to-cash system or into a human resources system from your software.

• Acquisition. This type of project is a world unto itself. It is usually initiated when the business wants to buy its way into a particular portion of the market and buy either expertise or revenue. The challenges from an architecture perspective include figuring out what it would take to build these capabilities yourself and also to figure out what it would take to integrate these capabilities into your existing suite of products while increasing the business’s overall value. An example of this type of project would be purchasing a start-up to fill a gap in your overall product portfolio or to expand your portfolio into a new high-growth area.

Be cautious when you see a mix of these project types, such as Migration + New; the features are likely to not have been well thought out, and the requirements are likely to be “Make it just like the old system except for this handful of items.” This type of mixed project is likely to go over budget and be completed well after the original planned release date.

If it is a truly large mixed project, the senior management leader is likely to not be with the company or have exited to another part of the organization before the project completes.

Alternative Ways of Financing Projects

There are typically two types of financing that are used to fund projects.

The first is a spending envelope. In this case, the business will likely ask for a yearly round of funding with a loose commitment to what will be accomplished. There may not be a specific ROI set for these funds. One of the advantages of this type of project is that if you don’t get a feature done this year, it may not be a large issue since you may be able to simply complete it next year. Be cautious about underdelivering, though; it can cause issues that are hard to manage. The ability to reprioritize knowing that future funding is likely to be available enables the business to be more strategic about its decisions and allows technology to do more of the right things. In effect, the business acts as a property owner instead of a temporary resident. This type of financing also limits the business in terms of what types of efforts it can take on—it’s fixed funding.

The second type of financing is project centric. This type is typically for a project that has a defined scope, a defined funding amount, a defined delivery date, and a specified ROI. One of the advantages of this type of project is that you can assemble a team that has the skill sets to address specific needs. This type of project typically requires that more tough decisions be made. Invariably, what the business wants to get done typically costs more than the available funds, which can lead to compromises in quality (“Let’s do less testing”) or fewer features (“This feature is too expensive or does not provide enough value”).

In both cases, estimating plays a critical role in determining the success of the project. If you have sufficient funding and resources, you can get the project done on time and on budget; you will look very successful. If you have a budget overrun, you will look as if you have been involved in a mismanaged project. In reality, the only difference between the two was the estimate and the associated funding that was applied to both.

The challenge is to get the estimate “right” and have some margin for error.

Understanding the Business Process

Do you understand how the business goes about asking for and obtaining funds that enable the development process? It is not uncommon for corporations to have a waterfall business process and an agile development process. This allows them to maintain relatively tight control over and measurement of how and where the development dollars are invested.

Do you know when the business plans to ship the product? In many instances, it is the proposed ship date of the product when the financial clock starts, and it may be not at all related to the actual start date of the project. When estimating, you need to be clear about when the project will begin (avoid putting in specific dates when possible) and when it will be delivered (make this relative to the start date).

Many factors outside of your control can influence when a project might start. For example, there may be a hiring freeze or a contractor freeze that results in your project not being able to start until other projects have completed and existing resources are made available. Meanwhile, finance considers the funds to have been delivered whether they are in use or not, and the countdown to delivery is has begun. Once the funds have been delivered, how does finance track you to your numbers? Is there any kind of margin (plus or minus 10%)? If you go above the margin, how do you deal with exceptions? Knowing this kind of information can inform you about how tight your margins can be. If there is no room for error, your estimate needs to properly account for that.

Developing the Architectural Approach

Architects are responsible for developing the architectural approach for a project during the estimation phase. This approach will serve as a backdrop for how the estimate will be formulated and will serve as an initial roadmap once the project begins.

Is This a Partnership or a Contractual Relationship?

Different business units operate in different fashions. Some will work with you as business partners and there will be open sharing of information in both directions. Others will work with you in more of a contractual manner, where the estimates you produce are fixed-bid estimates. They expect all of the features at the highest possible quality and delivered at or below the price specified. Knowing how a particular area of the business likes to operate can inform you about how you need to estimate and what contingencies you need to be prepared to account for in your estimate.

Depending on the nature of the relationship, you need to be prepared to defend your estimates at all times. You may be challenged by executives within the organization if they feel your solution is too expensive for what is perceived as “gold plating.” You may be challenged within your own organization if you provide a tactical solution to help the business meet a specific deadline. This tactical solution may be perceived as a hack that someone else will have to clean up, or it may introduce a scaling issue that unnecessarily uses up valuable resources. The key is to show you are being a good resident, and that there is a plan to address any technical debt that will be incurred.

Make sure as the creator of an estimate that there is ample backup material to make the estimate “real.” Estimates are always challenged if they are seen as too low or too high.

Sometimes the relationship between the business and technology can be more political in nature. The business may use the estimating process to prove a political point.

In a large organization, managers often use estimates to justify getting more people (resource headcount) or maybe even creating new positions. To accomplish this, they may need to deprioritize or shut down some other effort in order to free up resources for this one.

What Is the Business Rationale for the Project?

Once you understand what the business is asking for, you need to get a sense of why the business wants to pursue this project:

• Is the purpose to drive cost savings?

• Is the purpose to grow revenue?

• Is there a strategic first-mover advantage that the business is seeking?

• Is this a competitive move to quickly catch up to the competition and be a fast follower?

• Is the business hoping for a quick win?

• Is this an exploratory project? Is the business just trying to test the waters?

Understanding the business rationale for pursuing the project can help drive a solution that will enable the business to meet and exceed its objectives. This rationale can provide some leading indication of what the ROI may be for a project or even the total cost of ownership (TCO) for certain types of projects, especially for build-versus-buy decisions.

What Is the Marketing Approach?

Understanding the marketing approach for your products can help guide your decisions about what architectural directions you need to take into account. As you gather this marketing information, consider:

• Do you understand the marketing side of the world?

• How is marketing going to sell this product?

• What customers are they going to approach?

• Do they have customer personas?

• Have they done customer research?

• Does the product apply to multiple customer segments? If not, what changes or skins would be necessary to make it apply to multiple customer groups?

Taking the time to understand how sales are made and how the product is presented to your customers can help you craft better solutions and prioritize decisions about the approaches being considered.

Is This a Repeat Estimate?

Often for technology, a project that needs to be estimated has been around the block before. If and when this occurs, consider why new product development keeps asking for the same project, but with minor twists. Are they searching for the combination that has the least cost with maximum profit (customer benefit)? Are the reestimates based on new insights from customer visits?

In nearly all cases, proceed cautiously when reestimating projects (see Figure 4.4).

Figure 4.4. Proceed cautiously with projects that have been recycled and reestimated—understand why the project was not previously funded.

Consider separating the features and making it more of a buffet-style estimate, one where the requesters can pick and choose the parts they want, including alternatives. When you do this, make sure that critical dependencies are noted. Some features may have dependencies on others, and you don’t want selections to occur where there are hidden costs that were not accounted for. If there is a common core set of functionality among features, separate it out as a required portion of the estimate; this will help the requesters pick one of the alternatives or potentially both without under- or overcounting the effort needed.

The challenges are that giving a buffet-style estimate with multiple alternative options is expensive and potentially risky, can take a significant amount of time to produce, and may be challenging to present to the business in a simple manner. Ideally, it will fit on a PowerPoint slide.

What Risks Have You Identified? Can You Mitigate Them?

As you progress through the estimation process, the ability to identify and mitigate risk is one of the chief responsibilities of an architect. One of the best ways to mitigate risk in a new area is to do a proof of concept (POC). Testing the idea and validating the approach are invaluable if you have the time and funds. It has been my experience that doing a POC during estimating is nearly impossible. It is typically extremely hard to get POCs approved during, or prior to, estimating. The dollars are likely to not get approved unless there is “proof” of a reduction in cost savings or a growth in revenue or occasionally a strategic play. If at all possible, work with your technology management and business partners to look at funding these POC efforts. In the end, it is in their best interests to lower project risks and have projects succeed from a time, budget, and resource perspective.

The business typically has had the experience that most efficiency plays don’t pan out. Great claims are made, but they don’t materialize. The costs shift in other ways, and in the end, it looks like a shell game. You need to look at the total ownership costs.

As you estimate the development of the system, take time to consider these issues:

• Can you use virtual machines or cloud-based hardware when you will be first scaling/developing the system? In the long run, you need to be careful of what the real costs are—if your usage is high, you are probably better off with physical machines. You need to consider what the impacts will be on the overall ROI if you are forced to move to physical after initially selecting virtual machines or cloud based. Take the time to document what scenarios would cause you to make this course change. If one of these scenarios comes to fruition, you will be much better off having raised it as a risk.

• Do you understand the timelines of hardware needs? Given the normal slowness in bringing in new physical hardware, take the time to identify the critical dependencies for when the project kicks off.

• When do you need lower environments in place? Are there special hardware or software needs?

• Is operational development required (systems that have not been dealt with or set up before)?

• Do you understand where your customers will be located? Do you understand their potential latency?

• What kind of logging/diagnostic software do you plan to have in place? The ability to fully instrument your software can be a lifesaver when things go wrong in production.

• What kind of caching concerns do you have?

• Are there areas of the application that will be sensitive to network latency?

• Is big data involved? Are you prepared to process the large volumes of data you may be gathering, and do you have a plan to put it to good use?

• Do you know what the key cost drivers are? What have you done to mitigate those?

Many times, people estimate work and see only the happy path. This presents issues when the business hears of this lower cost, not realizing that the estimate did not take into account the risks or all of the other support costs associated with a project.

The key to reducing risk is to first identify it; then you have a shot at addressing it and adjusting your estimate if needed.

Are You Building a Platform?

Building a platform versus an application requires a very different approach. If you are trying to build a platform:

• Have you considered multitenancy?

• Have you considered internationalization?

• Is there a need to integrate with multiple business systems?

• What types of analytic tools are needed? Do you need to integrate with more than one?

• What other third-party tools are required? What about licensing costs? How do these licensing costs change as your usage increases, number of users increases, number of installations increases?

• What about security? Encryption?

• Will you allow users to inject their own custom code? If so, how?

• Do you understand the partitioning rules?

• Do you understand the variance in presentation between different applications that may be hosted on your platform?

• Do you understand the common and unique data required for each application and potential applications?

Platform estimates are more complex, impact more people in an organization, and have the potential to go wrong in a very public manner. For more information on platforms, see Chapter 6, “Platform Development.”

Are You Re-platforming?

Re-platforming an existing project can be a very challenging endeavor. Those holding the financial purse strings rarely want to hear the real cost and the effort involved to migrate to the new platform. When facing a re-platforming of a project, you will want to step back and take an innovative look at how you approach the problem:

• Can the new project be delivered in a manner such that it is a significant improvement over the existing product? If the improvements are dramatic enough, they can help justify an increase in revenue projections and help bolster the likelihood of obtaining approval of the project.

• Are there solutions that exist that you can leverage? Open source, cloud providers, and other alternative solutions may reduce the overall cost, shorten the delivery time, and minimize the maintenance costs of the new system.

• Are there ways to incrementally approach the problem? Being able to incrementally deliver value to your stakeholders through phasing will allow them to see positive results earlier and help mitigate financial risk. This may also allow those in charge of the finances to incrementally approve funding and adjust to market needs as time progresses.

• Are the stakeholders willing to reduce the overall requirements and simplify your product to areas that are essential and heavily used by your customers (the 20% that provides the greatest utility)?

Estimating a re-platforming project is one of the most difficult estimating efforts. Taking the time to consider and deliver multiple options for how to approach the overall effort can help mitigate the angst that typically surrounds these types of efforts.

What Technologies Are in Play?

The technologies that are selected during estimation can have a dramatic impact on nearly everyone’s perceptions of the project. New technologies can garner significant excitement in the technology ranks, raise concern from your business partners, introduce a host of operational concerns, and open the door to a whole new set of capabilities that were previously unattainable.

The challenge is to introduce a limited set of new technologies that will demonstrate clear value to the business, minimize operational risks, and keep technology modernized to continue to attract talent to your organization.

As you craft a set of possible solutions for the estimating effort, do you have time to

• Perform small POCs to help validate the viability of the technologies that are of interest?

• Show the pros and cons of different technology solutions?

• Identify the risks, assumptions, issues, and dependencies for the different solutions?

• Identify required legacy system integrations? Identify financial system integrations?

• Identify different approaches to the problem? Can you use Hadoop to solve the problem? Can you use a no-SQL database?

• Determine the general appetite for change? If it is low, do you really want to be there?

When you take into account all of the technologies, deployment models, and technology stacks in play, consider the impacts on testing, operations, and support. All of these items have costs associated with them and can help you validate the viability of your technology choices.

What Is the Organizational Structure?

Conway’s Law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

Melvin Conway

Judging from my experience, the software being developed reflects the organizational structure of both the organization developing it as well as the organization that is receiving it.

What is your organizational structure?

In large software projects, the team is unlikely to be fully colocated in the same site. If it is in the same site, not everyone is likely to be on the same floor. If they are on the same floor, it is likely that not all of them are within 50 feet of one another. (This is the maximum distance for team members to be apart for collaboration to occur regularly, according to MIT’s Tom Allen. This is less of an issue today with online collaboration tools, but close proximity definitely helps.)

As the architecture emerges and the key components become clear, consider:

• With whom within the area that is likely to receive the work can you review the approach?

• Who are your trusted partners?

• Are you assuming who will do the work? Things change.

• Do you have the ability to bring in contractors or contract out the work?

• Do you have the ability to colocate the team?

• If the team is not colocated, are they at least in the same time zone?

• Can you move the colocated team to an isolated area?

• Are there ways to minimize the number of dependencies with other organizations? Realize that coupling and cohesion are also factors in organizational structures.

• Can you eliminate all organizational dependencies and have complete control?

• Does the technology organization reflect the organization or market it is serving? If another area has a key skill that you need, it may be challenging to cross organizational boundaries to have that area do the work.

Do You Need to Seek External Research?

If you are moving into areas that your company has not previously dealt with on a regular basis, consider doing research on broader topics with companies like Gartner or Forrester Research. They can provide general industry direction and trends.

If you have something specific and more concrete, but still lack a level of expertise in an area, seek out firms (ideally, local) that specialize in what you are looking for.

Are there white papers? Websites? Blogs? Any information you can get to inform you is a good thing. Be cautious about investigating patents; that is legal’s job, not yours.

Have You Identified Leverageable Components?

As you progress through an architectural approach, consider:

• Are there other projects whose work you can leverage?

• Are the leverageable components nearly complete?

• Is funding guaranteed to complete the components identified as leverageable?

• Can you depend on the implementation working for you?

• Can you feed requirements to the other project?

• Can you give them additional funding?

• Can you add to their source code if there are slight variations for your use cases? If not, can you take a copy?

If there are any dependencies that are not guaranteed to be delivered, you need to include the cost of the work you need plus the cost to finish and test that work to ensure that you obtain an appropriate level of funding.

I have had several projects where those who promised software failed to deliver. Usually their business did not want to pay for the strategic solution; they typically cared only about funding the absolute minimum that met their own business needs. In such a situation, the challenge is that depending on the path the other business takes, you could be left empty-handed.

I have also seen situations where initially the business and technology promised support to develop the project strategically, took the money to do it strategically, but due to time constraints “hacked” the system.

Be very, very cautious about depending on other groups with loose or indirect ties to your project, especially when the work is not complete. If you do, clearly identify the dependencies in the estimate, and make sure that those at higher levels of the business are aware of what you are depending on and that there is an understanding of the dependencies, technical, political, and otherwise.

Generally speaking, if what you need is not in production, include the work to build the capability in your business case. If the other group delivers, you will have extra funds to cover other costs or maybe even additional features.

In general, treat the component supplier like an external vendor. This is not the time to let your guard down. A reasonable component supplier should welcome a formal agreement. It is a win-win for all sides.

Estimating Strategies

During the estimating process, there is a set of time-honored strategies to help the process run more smoothly, as described in the following sections.

Plan for Unknowns and Challenges

Make sure in your estimates that you include time for things to go wrong (for unknowns); nothing ever goes as planned. If you plan for things to go wrong, you will have sufficient resources to recover. If not, you are preparing yourself for a less than pleasant experience with the executives. They expect you to deliver regardless of what hurdles you encounter.

Be Realistic: Don’t Cave in Just to Get the Project

If you can’t get the numbers low enough for the business to be happy, it is okay for the project to go away. Being on a project that has half the money it needs is an awful experience (whether due to scope miscalculations or excessive hardware needs).

Keep the Critical Things Close

Try to seek to delight the customer, and build a system in which you have most control in areas that are critical to your success and your business (this is likely what makes you special and differentiates your product from others). Don’t build nonessential components; let someone else own and maintain them. When it comes to the maintenance cycle of nonessential components, it is not in your business’s best interest to invest money in these areas either now or in the future.

Develop Estimating Feedback Loops

Developing feedback loops for the estimating process will help ensure that you are learning as you go and will help increase the speed and efficiency of the estimates that are produced. As you do this, consider:

• Do you have a consistent way of capturing estimates? Reviewing estimates? Improving estimates?

• Do you have a feedback loop for comparing estimates to actuals? Functionality requested to functionality delivered? If not, why not? If so, what improvements can you make?

• What value does what you are doing bring to the table?

• Can you eliminate anything from the process?

Refining your estimating processes through feedback loops allows you to stay up-to-date with new learned best practices in the industry and helps keep your estimates aligned with business needs.

Minimize Organization Coupling and Cohesion

Organizations are just like software components. Tight coupling between organizational units can cause many problems. Organizational units need to have the ability to flex and change without the rest of the organization having to change with them. In a similar vein, you should work to keep highly cohesive aspects of a project within organizational boundaries.

PowerPoint as You Go

When developing an architectural approach for an estimate, it is usually best to capture the information you are gathering directly into a PowerPoint presentation. You are going to be asked to present it many times, and PowerPointing as you go naturally prepares you for impromptu requests to go over the status of the estimate.

The architectural approach is never fully complete. Deadlines will drive you to deliver what you have based on the timelines the business is seeking (which are normally very quick, usually a week or less for most of my projects).

Develop Checklists

One of the best ways to ensure consistent estimates is to develop and maintain checklists. As each estimate is delivered, take the time to go back and update your checklists to account for new learnings. The questions asked in this chapter may serve as a starting point.

Gain Executive and Organization Buy-in Early

As an architect, you are in sales. Before presenting the architectural approach you are about to roll out, you need to ensure that all parties have bought into it. This means you need to communicate early and gain buy-in with the executives and all dependent organizations that will be impacted by the approach you are recommending.

If you fail to gain early buy-in and begin asking organizations to publicly commit to a direction during the estimating process without having prior knowledge of that direction, you are almost always guaranteed to be faced with defensive posturing, a loss of trust, and a long estimating road.

Estimating Principles

During the estimating process, there are several principles to keep in mind.

Know the Hard Problem

This is the single factor that will determine the success or failure of a project. Take the time to find it and ensure that it is properly addressed or, minimally, properly documented.

Provide Options

When estimating, giving your business partners options will allow them to configure the project they want and compare the cost benefits of the options. They get to choose and feel as if they are in control. They are much more likely to be supportive of the decision going forward because they were the ones who made the decision.

Leave Design Decisions Open

Although you should understand at least one way of implementing a solution for the estimate, leave the final design decisions to when you are close to the problem; you and others may discover much better ways to address the problem.

Know the Schedule

When estimating a project, you need to have a sense of whether the desired deliverable date is achievable with a reasonable amount of staffing. If it is not, you need to communicate this immediately. Bad news early is much better than making commitments you are unable to keep and there is no time for an executive to step in and help remedy the situation.

Know What You Want

There are aspects of every project that you believe are critical to the integrity of the solution. Don’t compromise on these areas.

Avoid Being Negative

There are many ways to respond to people. Avoid being negative when others are questioning your approach; they are trying to help.

Seek Opportunities to Say Yes

When possible, seek ways to give your business partners what they are looking for, and try to give the development staff opportunities to work on the areas that they perceive as interesting. They will naturally be engaged and deliver more than expected.

Bargain Hard Now, Not Later

The time to bargain hard is during the estimating process. You need to work out known issues instead of avoiding them. An open conversation early on can bring the real issues to the forefront and help maintain commitments from others well into a project when they know you have dealt with them fairly.

My experience has been that it is extremely hard to add technology-related items once the estimates have been reviewed and approved, even when they turn out to be of strategic importance.

Don’t Cave In

Mild pain now; otherwise worse pain later. If you cave in on things that you are passionate about, your heart will not be in the project. You are far better off fighting for what you believe in and, if possible, fighting for the things others believe in. The road you travel will be much happier when it aligns with your convictions.

Trust Your Gut Feeling

If there is something that doesn’t feel right during the estimating process, dive into the area and learn everything you can about it. Your gut feeling is almost always a good indicator of whether things are on the right path and sized correctly. If possible, back up your gut feeling with solid data-driven information. You will need this if you get challenged.

Beware of Projects That Others Have Estimated

When you take on a project that someone else has estimated, take a serious look at what you believe the approach should be. If the estimate is bad, you need to get that into the open before you begin working on the project. The longer you wait, the more you are communicating that you agreed with the assumptions that were in place when you took ownership of the project.

Know the Business’s Targeted Build Price

The business rarely comes looking for an estimate without having given some serious thought to what it is willing to pay to build this product. Often, the requesters have already polled or asked for revenue sign-up from the different marketing segments prior to beginning the estimating process. Ask for the target build price.

Bringing It All Together

Once you have the project context established, an architectural approach developed, and a solid understanding of the estimating strategies and principles, you are ready to begin engaging the estimating team(s) to develop the estimate that is being sought.

Knowing Your Timeline

Do you differentiate between effort and timeline? Does the timeline shift based on when resources are available? When does finance begin calculating ROI? Sometimes it is as soon as the project gets approved and the delivery date is set even though the estimating process took nine months and 15 iterations. (Oddly enough, this particular project was successful and highly liked by the users. For those involved in the estimating, though, it was grueling, tiring, and rotated through multiple sets of business partners.)

Who Is Involved with Estimating?

One of the key elements of getting a reasonable estimate is to have those who will be doing the work or have recently done similar work involved with producing the estimate. This is typically done by lead developers, those who are going to do the work or oversee it on a daily basis. If possible, try to avoid having managers or directors give estimates, and respectfully decline including VPs who offer up numbers.

Are there specialists in particular areas that you need to draw in? If they have estimated this type of work before, it is likely that they have standard estimates for the work being done (such as a certain number of days per style sheet). If you get estimates back from such specialists in something other than units of days, be very cautious; it is unlikely that they fully understand the scope of what is being requested.

Do those doing the estimate understand the likely ratio of contractors to employees? If not, again be cautious about the estimate; this is an area that can quickly bust a budget.

Understanding Your Leverage Points

Where does the functionality live within the organization? If you are trying to leverage work in another business unit, good luck. If the asset is built and owned by the other business unit, you will be at the bottom of their priority list when it comes to decisions. If it is built by the other business unit, but owned by the center (the corporation), you have a shot at sharing in prioritization and adding funding without ceding control.

Typically, most business units do not work well together; they are incented to look good themselves. They do not want another business unit distracting from their need to meet revenue goals. Proceed in these areas with caution.

Putting It All Together

Can you put together a one-page picture of how the solution will work? Are there a couple of alternatives? What are the pros and cons?

What are the risks? What are the assumptions being made? What are the outstanding questions? What are the issues? What are the concerns? What are the key driving requirements? What is the history behind the project? What has changed? What is different?

Shoot for a ten-page deck (title, outline, ask for questions, and seven real pages). Think about the main message and key takeaways and actions you expect as a result of how you have presented the information.

Engaging Executives

Be prepared to be examined by the executives about

• Why the numbers are what they are

• The alternatives that were considered

• What risks have been mitigated

• What risks currently exist

• What dependencies exist

• Whether there are other solutions

• Alternative requirements that could be used and still meet the business needs

Do your homework so you have all of the answers or at least an explanation of why you do not have an answer. Present the information at a very high level, but be prepared to speak to at least two levels of detail deeper than the level you are presenting at (see Figure 4.5).

Figure 4.5. Executives like to deep-dive into specific areas where they sense weakness and will keep drilling down until they find it. Be prepared for this behavior.

Selling the Estimate

Make sure the leadership of the estimating team is in agreement, including your management. Make sure they are on board with the approach that is being recommended and that everything has been accounted for. In the right environment (you are truly partners with the business), it may be okay to give the business partners a sneak peek at the estimates; otherwise, don’t publish the estimates until you have alignment with your leadership. Generally, be cautious with sneak peek estimates. Sometimes the recipient forgets that the estimate is just a sneak peek; that can be good or bad depending on whether the estimate is high or low. Before distributing the estimate, validate the following:

• Have you cross-checked all of the numbers?

• Are there gaps/overlaps in testing?

• Are there gaps/overlaps in hardware?

• Are other groups’ assumptions that work is being done actually accounted for? Do those groups know they are doing the work?

• Are you assuming that another group is doing work but not explicitly funding it?

• Do you have an explicit agreement that the other group is in fact willing to do the work?

• Does this agreement come from a more senior-level person (director or above)? If so, do you have a commitment on the timing?

• Is the other group reengineering their system or in a major project? These commitments are not likely to be met, and you are a lower priority.

• Have you included time for user experience (UX) testing, for operations, for deployment, for fit and finish? Architect, project management (PM) time, scale testing? Hardware? Licensing costs? Should you consider an enterprise licensing agreement?

• Do you understand the system characteristics (concurrency, locking, caching, security, etc.)?

• Do you know the major components (persistence, user interface, batch, extract-transform-load (ETL), warehouse, operating system, business systems, etc.)?

• Are there internationalization needs?

• Are there reporting needs?

• What kind of service-level agreements (SLAs) are involved?

• Are there any safety concerns? Does the system in any way affect humans?

• What are the performance concerns? Availability concerns? Scalability concerns?

• Are there natural coupling and cohesion of major logical components?

• Is the business willing to incrementally fund this?

• Are there regulatory concerns (U.S. or international)?

• Does the placement of information/servers matter?

• Can you implement this out in the cloud?

• Are standard languages required? Is there flexibility?

• Are there unknown areas? Things that you have not implemented before? Are the unknowns simply unknown to your area? To your company? To the industry? To the world?

• Are there quick spikes that could be done to remove the unknowns?

• Can this be staged?

• Does the business partner have a budget in mind?

• Has the architect group or chief architect signed off?

If you follow the process, you are unlikely to have too many issues. You are going to be challenged as people try to understand the architecture you are proposing, but as long as you have detailed information and reasoned thinking behind your decisions, it’s all good.

Just remember, you are a service provider: give accurate answers and, if you make a mistake, admit it. Give context; the business drivers and assumptions may have legitimately changed.

Summary

The road to estimation begins with

• Understanding the purpose of the estimate being sought

• Understanding the project context

• Understanding the estimating process

• Developing an architectural approach

• Knowing the estimating strategies and principles

• Knowing how to bring it all together

For me, estimating is one of the more challenging aspects of being an architect. It is fun and exciting to learn new things, but being given a relatively short amount of time in which to develop an architectural approach and being prepared to defend it to everyone in the organization is challenging and forces you to think on your feet.

References

Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Addison-Wesley.

———. 2005. Agile Estimating and Planning. Prentice Hall.

Hunt, Andrew, and David Thomas. 2007. The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley.

Leffingwell, Dean. 2007. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley.

———. 2011. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley.

McConnell, Steve. 1977. Software Project Survival Guide. Microsoft Press.