C H A P T E R  3

Achieving Desired Results

All throughout a project—and in the end—results matter. Good results can build trust and poor results can destroy trust. Results are how you and your team are evaluated. Consider a typical project situation: everything is aligned to produce the results you get. The way people interact or do not interact, the hardware, the software, the staffing, the planning or lack of planning; these and many more influences yield the results. When the situation improves, there are better results. But bringing about organizational change is very challenging and is likely outside the influence of the team and its members. The goal of this chapter is to raise your awareness of specific changes you can control or influence and provide pragmatic and helpful techniques to realize better outcomes.

This chapter is about being results oriented. As a developer or a team leader, positive outcomes come from taking practical approaches and concentrating on objectives. First, there is the planning that goes into making sure things start off right. You create the conditions for success by spending time listening and communicating about what the desired results are or should be. Achieving desired results is about making the effort to sort out the practical from the impractical, and about delivering, accomplishing, and showing positive outcomes. At the same time, a big part of achieving desired results is not allowing less important things or avoidable problems to divert or distract.

Since just about every project involves people trying to work together, it goes without saying that people skills play a big part in what is achieved or not achieved. The Agile Manifesto recognizes the importance of individuals interacting by listing this as the first value.¹ This chapter presents practical advice on how to get team members to collaborate with each other and work toward a common purpose.

The practices covered in this chapter are summarized in Table 3-1.

Success Conditions

How a project starts often makes the difference between success and failure. If the conditions are right from the beginning, the project often maintains favorable conditions. The team keeps coming back together and regrouping when problems and challenges arise. When the wrong conditions exist from the outset, bad things, like conflict and confusion, remain. Soon, misunderstandings lead to more misunderstanding. Conflicts continue. Expectations are missed. Thrashing is never-ending.

There are projects that seem doomed to fail from the beginning, in which everyone knows that things are going to fail from the start and freely admits it. A different scenario is where everything starts off fine, and it is only in retrospect that the project seemed doomed. Sometime after the project fails to deliver or is cancelled, someone mentions that the project was hopeless and others join in and agree. It is as if everyone on the project knew that the project started out wrong and was prearranged to fail. If you were to interview the team and dig further you would find two things missing all along: awareness and acknowledgement. Either they were not aware that the project lacked the success conditions, or, if they were aware, they did not acknowledge the severity of the problems. Silently, the team members allowed the project to start off wrong and kept quiet as things continued to run badly. It was not until it was too late or in retrospect that failure seemed the likely outcome.

All project team members must take an active part in the project. Every individual must work hard to be aware of potential problems and raise their voice when success conditions are absent. The goal is not to eliminate problems but to raise awareness and get everyone to acknowledge problems, risks, issues, and concerns. On any given project, an individual can help everyone see the hidden flaws, point out undue optimism, and insist on a reasonable plan of approach.

Projects that have the right success conditions have few interruptions, intrusions, and interference; the project work is considered too important to disturb. In contrast, projects with a lot of stopping and starting, team members who join and leave, and external meddling and prying, are inevitably late, over budget, or fail. It is hard for individual team members to deal with all the task switching. Developers find it especially difficult owing to the nature of development work. Programming and debugging require a lot of concentration and a good short-term memory. A lot of task switching can destroy developer effectiveness. Developers need to work together to communicate and coordinate. This means they need to have a lot of available time to talk and work together, and to develop an understanding and a rapport. Everyone on the project must raise awareness and work to limit diversions, distractions, and disruptions that destroy project success.

To this point the success conditions are defined by context and preconditions; it is hard to change or even influence the circumstances. You cannot avoid the types of problems that arise at this stage. You cannot stop their reoccurrences. These problems include things like team members' aptitude, long-standing grievances, and no training budget. The goal is to find coping strategies and ways to minimize the impact. Even as the project gets underway, however, there is one area that can improve: the capacity of the team members to deliver. This often comes in the form of on-the-job training and mentoring. In broader terms there are three areas to improve: knowledge, skill, and attitude. These areas of development are illustrated in Figure 3-1.

Figure 3-1. The conditions for success: knowledge, skill, and attitude

Knowledge is concerned with recognizing and understanding what to do. For team members, there is knowledge about many topics, such as project objectives, technology, reasonable plans-of-approach, features, coding standards, working with other teams, and many others. Clear, consistent, and complete communication is the way knowledge is transferred to and within the team.

Skill is about knowing how to do something. It is about experience and training and climbing the learning curve. Without the right skills, knowledge cannot be turned into action. A developer that lacks a crucial skill can appear stuck or unmotivated. Few want to draw attention to the fact that some competency is lacking, but without help there is no progress. Recognize the fact that without skill-development the results will suffer. Training, self-paced tutorials, demonstrations, and mentoring are all ways to develop skills within the team.

Attitude is about knowing why to do something and wanting to do it. It is about motivation and interest. Without the right attitude, even if the knowledge and skill are present, results lack efficiency and creativity. A developer without the right attitude can be blatantly uncooperative or quietly unproductive. There is an important sequence here, illustrated by the arrows in Figure 3-1. First, spend time to figure out if there is missing knowledge and discuss that. Then, spend time working on skills and proficiency to figure out if there is a problem in that area. Finally, if you are sure that a problem does not stem from lack of knowledge or skill, then focus on attitude. Spend time listening and diagnosing the problem. Once you fully understand the cause of the problem, solutions will present themselves.

For any project to be successful, the proper conditions must exist. As an individual team member you are able to gauge your own knowledge, skill, and attitude. Team leaders need to have a regular, open dialog with team members. Both one-on-one and in groups, ask team members to consider these questions:

• Do I know what to do?
• Do I know how to do it?
• Am I motivated to do it? If not, why not?

These questions apply to all aspects of the project, from requirements to technology to specific practices. These questions apply to all objectives and priorities. Table 3-2 lists a few possible priorities and examples of some of the knowledge, skills, and attitudes that might relate to that priority. For example, if correctness is a high project priority, then automated unit testing with the NUnit framework may be the way the team decides to address it. However, in this example, one team member does not know that automated testing is a serious priority, another does not have any experience with unit testing, and a third is skeptical of the benefits.

Knowledge is improved through communication and understanding. For example, in this case, keep repeating again and again that automated testing is important to you. Ask team members about the automated testing they are doing. Measure test coverage percentages and share the results.

Skill is improved through training and experience. In this case, there ought to be hands-on examples of how to write proper unit tests. The test code needs to be reviewed. The focus is on learning and improving. Talk about project prerequisites, such as formal training. Add time to the schedule for mentoring and on-the-job training.

Attitude is a lot more complicated than knowledge and skills; however, it may be more important. There are no easy answers. Some negative concerns reflect real project dilemmas that ought to be addressed. The first priority is to become aware of the team member's honest attitudes, for better or for worse. Build off an acknowledgement that their rationale is important to get out on the table. Dialog is good even if there's no real solution. Perhaps the result is a statement of reluctant support: “I am not convinced automated testing is the right approach, but I will support it because I want to see the project succeed.” An openly supportive skeptic is a lot better than a quietly unsupportive skeptic.

Project Inception

Every project starts with some initial period of time when things are just getting going. On some projects this is just an informal kickoff period when team members begin working together. On larger projects or with formal processes, there is a project inception phase. The team is forming, and everyone has a different idea of what the project is all about. As you would expect, there are differences. Some of the team members are excited to be using a new tool or technology. Some are expecting to have detailed requirements fully written up with use cases and scenarios. One is disappointed and angry that he is not the team lead. Others fear that the goals are unrealistic, the deadline unachievable, and expectations are way too high. Excitement, anticipation, anger, and fear; there is a lot of emotion before the project has really started.

First and foremost, project inception is a period of knowledge transfer. The project leaders must discuss and communicate with each other to ensure they are clear on what the project is all about. These leaders must then communicate to the team in consistent terms and expectations. The whole team must have an open dialog that completely covers topics and includes questions like the following:

• What is the business justification for the project?
• What is the project scope? What is definitely out of scope?
• What are the key features and objectives that drive the architecture?
• What are the candidate technologies and plans-of-approach?
• What are the identified risks? How will they be mitigated?
• What is the preliminary project schedule and budget?

Too often projects get started with a lot of lingering questions. Team members should not make assumptions. The tough questions need to be asked. Individuals must make and test assertions that press these issues.

During the inception period it is very important that everyone see the same big-picture concept. Everyone must know what deliverables are to be delivered. This is the time to both share the vision and have a meeting of the minds. As an individual team member, you must remain alert to any differences you are seeing and actively point them out.

Out of Scope

Perhaps more important than specifying the system's requirements is deciding what is definitely out of scope. People are reluctant to talk about what is not going to be done. Assumptions are made, which lead to future misunderstandings and unmet expectations. For example, developers must not automatically assume that globalization is out of scope. If you think globalization is out of scope then make that assertion and insist that the project manager record that it is not an objective.

Take the time to list out all features and functionality that are out of scope. Be sure that the list is explicitly clear and completely detailed. The goal is to remove any assumptions, which lead to later misunderstandings.

Diversions and Distractions

Time is a resource you spend whether you want to or not. Any project can save money by not spending on servers, software, and training, but time marches forward. This is why diversions and distractions cause developers to fail to achieve desired results. Many interruptions and intrusions eat into precious development time.

One way to limit diversions is to cap the time spent on concerns that you can neither influence nor control. Use those criteria to estimate the value of spending time on a specific topic. For example, if you feel you have no influence on a decision, but getting to a decision is important, then put your time and effort into setting a deadline for the decision. Avoid spending time and energy on things you have no influence over.

Another way to limit diversions and distractions is by facilitating effective collaboration and communication that does not intrude and impose on the developer's time. Establish a set time to hold a very short meeting, such as the daily standup meeting favored by agile development. Prevent distractions, delays, and progress blockage by using collaboration tools like discussion boards instead of ad-hoc disruptions and the unreliable relaying of information from one developer to the next.

Almost by definition, something that distracts is not important to you or your team. It may be important to someone else, but their priorities are not your priorities. Take a moment to consider these questions:

• Is this issue or interruption important to me or the project?
• Where is the urgency of this issue or interruption coming from?

When an issue comes up, it may only be important to one person. A production crisis is important because users are impacted, but addressing a technical support question that the help desk ought to handle is unimportant. An executive's concerns are important because retaining that person's support is important to the project, but analyzing a favorite feature that is not in scope is unimportant. Someone intrudes on your time because it is important to them, but you are responsible for figuring out if it is important to you and your team. When unimportant issues are raised by important people, an effective strategy is to pivot the conversation from the specifics of the issue to a discussion of competing priorities for time and resources. It is amazing how quickly awareness and acknowledgement of your priorities changes things.

The Learning/Doing Balance

Developing a new skill can increase efficiency. Finding a better approach can dramatically improve a situation. Better practices do lead to better results. There is no doubt that you must spend some time learning to be more effective. To be more productive you must increase your capacity to produce. However, if you spend too much time learning then you cannot be productive. The learning/doing balance is about appreciating both sides of the equilibrium. Consider these questions:

• Will gaining new knowledge and understanding be more helpful than applying what I already know?
• Is the desired result to see developers gain greater competence, capacity, and efficiency, or is it to see them produce immediately?
• Will applying current know-how and practice be more useful than developing new understandings or better insights?
• Is there a belief that less effective, short-term results are more important than improved, long-term results?

Achieving desired results is about striking the right balance between increasing the capacity to accomplish and actually getting things done. There are many tasks that cannot be done properly without basic knowledge, yet there are some things that cannot be learned without doing. Most of what is taught in school and in training courses is the basic knowledge. Riding a bicycle, driving a car, and facilitating a meeting require experience to gain mastery. Know when to learn and when to apply what is already learned.

Common Understanding

Without a common understanding there is no agreement. Any differences in understanding are sure to cause problems. It could be a simple difference of fact: one person thought the decision was to put the control on the left-hand-side of the screen while another thought it was going on the right. It could be a difference in opinion: one thinks it is better on the left but another thinks it is better on the right. It could be a difference in priority: one thinks the users find it more usable on the left while another feels it is more obvious on the right. Reaching a common understanding of facts, opinions, and priorities is important. This practice is about working to gain that common understanding. At the high level, frequent misunderstandings center on project objectives, success criteria, and contending values. At the detail level, misunderstandings are about requirements, tools, technology, patterns, approaches, standards, and guidelines.

Watch for the warning signs of misunderstandings: unclear objectives, vague success criteria, dubious value. Keep the individuals interacting until the specific differences are identified. Use clear diagrams and drawings to pull out facts from people's minds so that everyone can see them. As for opinions and values, decisions need to be made by the person or persons responsible for them. Discussion is a good way to reach consensus, but an authority decision may eventually be needed.

Wireframe Diagrams

Pictures are often a lot better than words. Many users cannot describe what it is they want, but they know it when they see it or when they like it. Why spend time discussing and describing what cannot be envisioned? Drawing at the whiteboard or creating a diagram helps everyone take their mental image and construct the same image.

User interface (UI) prototyping is often seen as an effective way to show what the results will look like. These UI prototypes tend to have two significant drawbacks:²

• There is some turn-around time from when the idea is discussed and the prototype is shown. The best UI prototyping tools still have a lag time that inhibits collaboration.
• A prototype can leave the wrong impression, with respect to completion. Many times it is only the developer who knows the extent to which a prototype is incomplete or fatally flawed. The primary design-drivers behind a prototype are haste, shortcuts, and illusion. This is a bad foundation for further development. Unlike a concept car or a model of a building, most users cannot distinguish between the software prototype and the expected result.

Avoid UI prototypes and favor wireframe mockups.

Wireframe diagrams offer an effective way to model and visualize. They strike a balance between collaboration and not leaving the wrong impression of completeness. With a wireframe mockup tool everyone can work together to fill in gaps and reconcile differences. Figure 3-2 shows an example of a wireframe mockup created with Balsamiq, a wireframing tool. In this illustration, the wireframe shows what information needs to go on the screen and what the user is able to do on the screen. Annotations explain specific rules and limitations. The purpose is focused squarely on arriving at a common understanding. This helpful activity pictures the screen and addresses topics such as

• Information to display
• Features and actions available
• Main purpose and areas of emphasis

• Rules, limitations, and options
• Use cases and scenarios

Time spent on wireframe mockups should focus on three topics: presentation of information, navigation within and between screens, and the layout and usability of a screen.

• Presentation of information is about what needs to go on the screen and how it can make things easy to read and understand.
• Navigation is about screen relationships, options to move around, and the workflow.
• Layout and usability are about the user interface design, which includes graphics, links, buttons, select-boxes, and other common UI elements.

Figure 3-2. Example wireframe mockup using Balsamiq

Documented Architecture

The high-level design of the system brings order to development. With a good architecture, the detailed design and development aligns to the decisions and direction communicated between the project stakeholders and the development team. This alignment is important to establish a framework and an outline of the hardware, software components, interfaces, and interactions. The architecture is a common understanding of the solution strategy for the project.

The architecture must document, diagram, and communicate the high-level design of the system to include the following:

• Software components and their interaction
• Core technologies and toolsets
• Driving requirements and priorities
• Technical and non-technical constraints
• Important principles, guidelines, and standards

Report Mockups

Although not every system has separate reports, many do. The reports can represent a significant amount of work; they imply requirements for the database and are drivers of the design. For example, there are the requirements for how the reports display the data. There are requirements for the data that needs to be queried. Unfortunately, not enough attention is paid to reports early in the project lifecycle. This practice is about developing a common understanding of the reporting requirements of the project and providing the developer with enough detail to deliver proper reports.

Everyone ought to see the reports visually represented. Using a spreadsheet is an excellent way to mock reports. Real numbers with actual totals can be shown. The layout, fonts, and other visual elements can be shown. More importantly, a spreadsheet is something analysts can use to collaborate with users and keep the requirements up to date.

For each and every report use a spreadsheet, such as Excel, to create a mockup of the report. Include representative data and have every total and calculation accurately shown. The goal is a clear and complete understanding of everything that goes into making that report. Try not to short-circuit the process, otherwise important detail is going to be overlooked. As a developer, follow the data back to its source and resolve any inconsistencies or missing data in the database.

Detailed Examples

Too often the examples that are supplied to developers are too simplistic or incomplete. This is especially true for infrequent scenarios or exception cases. Initially, simple examples help to explain the concept and focus on the primary use cases. However, software systems are required to properly handle the more elaborate usage scenarios. As the requirements progress from the high level and get into the detail it is a lot more important to keep the detailed examples coming. A deeper common understanding comes from sweating the details.

Complicated algorithms and business rules require detailed examples. To write code that implements these algorithms and business rules, developers need to understand the details and verify that the code meets all of the requirements. Trivial examples lead to trivial code. Many complete and detailed examples help an effective developer unit test and correctly implement the code. Detailed examples also help with debugging and troubleshooting. The full intention of the code is better understood with examples.

All through the project, from requirements to testing, keep asking analysts and testers to provide detailed examples of how the system is supposed to work. Ask that wireframes be filled in with sample data. Ask that report mockups show proper data. Ask that business rules be spelled out with examples and illustrations. Ask for data that reproduces defects and errors. Pressing for this information is important to properly develop, diagnose, and resolve many of the significant project issues.

Build an Archetype

Establishing an archetype is about creating a prime example that other developers should imitate and follow. An archetype is a prototype written in a specialized way; it ought to be imitated. This approach recognizes that many developers learn by example. If it is clear that there is an established archetype then their work can start by emulating a good model of the system. This practice is about creating models that others can and should follow. Other benefits of an archetype include

• Proving out the architecture
• Making abstract ideas real
• Allowing other developers to react to and improve the design

In addition to being a standard, the archetype helps to confirm and prove out the architecture. The high-level design started on a whiteboard or in the designers' heads. The ideas and approaches need to be proven. Build the archetype in such a way that it contains functionality that passes through all the layers of the architecture.

Many developers learn by example. Learning a new architecture involves either building something with it or referencing an existing model. A good archetype is like a tutorial that walks the developer through a modestly-sized, across-the-board application. When ASP.NET MVC first became available, one of the best ways to learn the concepts was to build the NerdDinner application.³ The NerdDinner application is an archetype, serving to communicate “what to do” and “how to do it”.

A good archetype is a lot clearer than many explanations. Many developers can react to and improve upon an archetype. Their suggestions are often very helpful. Many developers are “show me the code” oriented and are impatient with explanations and debate. They want to see a working example of the architecture and development style. In fact, the archetype is effective at solving the dilemmas associated with sorting out knowledge, skill, and attitude. For developers who have the proper attitude, the archetype is all they need to become productive. For developers who have genuine concerns, the archetype provides a way to discuss the specifics.

Create an archetype with enough detail to serve as a model for other developers to follow. Sometimes called a “vertical slice,” the archetype is a top-to-bottom example of how the system is intended to work. It need not be a separate application. In fact, it is often better to work through a significant area of functionality. The important idea is to expect that other developers imitate the coding style, design patterns, and approaches. The archetype is the model you want others to follow, by and large.

Desired Results

The desired results of a project focus on the software that is delivered. There are many positive outcomes to achieve but without working software, most projects are judged to have fallen short. In general terms, the working software is the primary deliverable. Secondary deliverables, such as documentation, are important, but should not come at the expense of the primary deliverable.

In software projects, activities are not results. All activities must serve the purposes of obtaining results. On a day to day basis, programmers talk about writing code, but in the final analysis delivering quality features and functionality is how the programmer is evaluated. It is the positive outcomes from writing software that the project stakeholders are looking for. There is an expectation that all activity leads to positive outcomes.

Deliverables

Every deliverable represents some tangible or intangible thing. It could be an installation package or it could be the ability to save a loan application. In the first case, the installation package is a tangible file on the network somewhere. It is either there or it is not there. It either works or it does not work. In the second case, the user sits down to the system to enter a loan application. Assuming the user is entering the application properly, the system either lets the user save or it does not. Saving the application is the intangible deliverable of the user accomplishing their work.

In the final analysis, desired results are strongly tied to good deliverables. Measuring progress with interim results is important. Properly sized deliverables are either done or not done.

A focus on deliverables should be results oriented. It can be described in objective terms, such as level of completeness, correctness, or consistency. Users see and experience deliverables. As a developer or team lead, focus on the deliverables and not the activities. Yes, the activities are important, but only insofar as they generate quality deliverables.

Positive Outcomes

One way to look at desired results is through the lens of satisfaction and quality. Customers and stakeholders are satisfied when the anticipated and expected features and functionality are delivered. Complete quality is when every requirement is met and the system serves every useful purpose. Consider a new car buyer. During the initial shopping period the customer focuses on the car's styling, bells and whistles, and various features. There's a lot of attention paid to a long wish list, but a car's indispensable purpose is to provide transportation. That can be taken for granted. The same is true for the structural quality. The customer implicitly expects the car to be well-engineered and reliable. While shopping, many car buyers are focused on what they want and not on what they expect. However, during the first year of ownership customers become keenly aware about whether the car is useful or not. After a few years of maintenance costs and reliability issues the structural quality becomes important.

Achieving long-term success depends on long-term satisfaction. For many projects the emphasis is always on features and functionality. In the earliest stages of the project the users and analysts focus on the wish list and what the current system cannot do. The minimum requirements and essential behavior are taken for granted. As the project continues, the quality assurance team focuses testing on the features and functionality of the system. This is referred to as “fitness of purpose” testing.

The system's end-users and customers are able to assess their satisfaction by comparing it to how pleased they are with what the software does or does not do. The testing team is able to gauge the quality of the system against the requirements. There is a favorable reception based on meeting the minimal, essential features and delivering wish-list items. Unfortunately, what results is a system that may be structurally unsound. The nonfunctional pieces are not in place and soon the initial happiness is replaced with dissatisfaction. Slow performance, bugs, scalability problems, and other nonfunctional deficiencies destroy trust.

Figure 3-3 divides satisfaction and quality into four quadrants. In quadrant 1 are the expected features and functionality that define basic quality. The outcomes in quadrant 2 are about building a robust system with reliable and performant code. In quadrant 3 outcomes are about the satisfaction that comes from getting more than was expected. In quadrant 4 the system is technically elegant, well written, and wonderfully designed.

For many projects the requirements are overly focused on the quadrant 3 outcomes: the wish list. As the project proceeds, completion is evaluated through testing that focuses on the outcomes in quadrant 1. For some projects these are the only two focus areas. It is during acceptance testing or after deployment that the quadrant 2 outcomes are put to the test. If the results are unsatisfactory then complaints about performance, reliability, and scalability start flooding in. A system that once looked good starts to look bad. As for quadrant 4, when the outcomes are not achieved the problems are usually internal to the system, but the implications of spaghetti code and restrictive designs are very real and show up in maintenance and enhancement costs.

Figure 3-3. Quadrants of satisfaction and quality

To achieve positive outcomes that hold up in the long run there needs to be a logical sequencing of the project focus areas. Both quadrants 1 and 2 are foundational. It is necessary to perform much of the work that relates to these areas. This is especially true of requirements that relate to structural quality and performing structural testing. However, the overall system cannot neglect any of the four quadrants. The highest level of satisfaction comes from delivering in quadrants 3 and 4, but never to the exclusion of quadrants 1 and 2. Here is more detail on what is in each quadrant:

• Minimal, Essential: The basic features and functionality, which is the primary focus of the project. Working in outcomes in this quadrant is about delivering “the right things.” Delivering results in this area is about both meeting the expected requirements and making sure the system does everything it needs to do. This is the expected. This is the system's capacity to serve its useful purpose.
• Robustness: The strength of the system is the secondary focus of the project. Working on outcomes in this quadrant is about delivering “in the right way.” Delivering results in this area is about the structural soundness, performance, reliability, and dependability. These are the expected nonfunctional requirements.
• Wish List: The things that are desired or wished for is the third aspect to focus on. Working on outcomes in this quadrant is about delivering “the desirable items.” Delivering results in this area is about adding functionality that users and customers are hoping for. These are beneficial features and functionality.
• Craftsmanship: Uncommon quality is the fourth aspect to focus on. Working on outcomes in this quadrant is about delivering with “superior experience and expertise.” Delivering results in this area is about things like technique, insight, anticipation, and future-proofing. This produces surprising quality.

It is with these four quadrants in mind that the objectives, metrics, and expected value can be sorted out. Since all these aspects are important, objectives within each should be established. List all the objectives and how they relate to a focus area. Find ways to monitor or evaluate or otherwise measure each of them. Be sure to point out how too much focus on one quadrant reduces the focus on another. Short-term pressures will push out long-term value. Remember that the things customers or users value today are not what they value in the long term.

This practice applies to either an individual or a team. Find a way to compare your results to the objectives. For example, a primary objective is to make sure the feature allows users to get their job done. Find a way to compare results with a metric or measure. For example, all of the project's minimal and recommended .NET framework guidelines are followed. Find a way to compare results to a focus area. For example, what has been completed so far needs to be tested under heavy use to be sure the system can scale properly. Positive outcomes are about more than immediate results; they are about achieving superior quality and exceeding expectations both in the short term and in the long term.

Trends

The desired results need to be viewed from more than just a single point in time. The trend over time is also very important. A graph that shows the trend communicates the rate of improvement. People have a difficult time appreciating the relationship between events that are disconnected in time. A trend graph can show how a better practice is slowly delivering the desired results. Conversely, it can show how the situation has deteriorated over time in the absence of an important practice. It is important to keep track of the results over time. It is important to know how the current situation relates to the past.

Trends help identify practices that work and those that do not work. Trends identify systemic problems, points of variation, and leading indicators. For example, if a graph that tracks the number of passing automated tests unexpectedly drops then it is an indicator that something noteworthy has changed. It might not be terrible, but it is important and worth investigating. If it is detrimental to the project then the change in trend sounded the alert. The burn down chart used in agile software development is an example of an important trending technique.⁴ The burn down chart shows how completed work is being accomplished over the course of the sprint and compares the actual outcomes to sprint planning and expectations.

Take some time to ensure that results data is collected at regular intervals. Use effective charts and graphs to visualize the trends. The goal is to understand how the situation is changing over time. It is important to create in your mind and the minds of others an appreciation for progress, abrupt change, or the need for improvement.

Summary

In this chapter you learned about achieving desired results. The first section discussed the success conditions and how all project participants need to take an active part in the project. The chapter also covered the importance of raising awareness and acknowledging gaps in knowledge, skill, and attitude.

You learned about the importance of common understanding. This chapter covered several specific techniques that foster agreement and draw out differences in understanding that might exist. These techniques included wireframe diagramming, documenting the architecture, creating report mockups, insisting on detailed examples, and building an archetype.

You learned about the importance of deliverables as opposed to activities. Special attention needs to be paid to both the short-term and the long-term positive outcomes of satisfaction and quality. In the final analysis, achieving desired results is measured against the objectives, key metrics and measures, and the overall value.