Engagement Management

a reference chapter in Software Engineering for Internet Applications; revised November 2003
This section was primarily authored by Cesar Brea.

Most of this book is about building a great experience for the users. In parallel, however, it is important to ensure that you're creating a great experience for your client and his or her sponsors during your team's engagement with this client. These are the folks who will pay the bills and sing your praises.

Whether or not your praises get sung depends primarily on whether the application that you build delivers the benefits your client expects. Thus it is important at all times to keep in mind an answer to the question "What does my client expect?" One comforting factor is that you have a lot of control over the client's expectations. You are preparing the planning documents, you are writing the schedule, and you are bringing agendas to meetings with clients.

This chapter presents an engagement management worksheet, a lightweight tool for managing your relationship with the client.

Definitions: The worksheet has five sections:

We recommend you go through this formally with your team at least once a week. You can also use it to structure introductory and update meetings with your client, though the worksheet is primarily for your team.

About the Organization

To contribute to discussions about scope and which features are critical, you need to understand what the client's organization is trying to accomplish as a whole. It helps to know a bit about not just the organization's purpose, but also about its size, resources, and trends in the its fortunes.

It also helps to understand your client personally, and to understand his/her place and influence in the organization. How much can be forced through? What must be proven before the application will get support from higher management?

Organization Name 
Organization Purpose (does what? for whom?) 
Organization Size (#people? annual budget?) 
Organizational Performance (revenue/ profit/ budget trend, actual vs. plan) 
Sponsor's Name, Title, and Organizational Role/ Level (person whose budget is paying for this, or who is accountable for business results the application supports) 
Client's Name, Title, and Organizational Role/ Level (person responsible for what gets delivered) 
Business Goals Served by Application (doing exactly what "better, more, faster, cheaper", quantifiably how much?) 
Client Clout (leader, has say, follower?) 
Client Tenure In Job (new, mid-term, leaving)  
Client Technical Knowledge (none, some, lots)  

About the Application

You want to document at a high level what the client wants, what you think the client should want (if different), and if there are differences, what the plan for persuading the client to follow your lead is. Some of these items are confusing and they are explained below.

TopicWhat the Client WantsWhat We ThinkPersuasion Plan*
Capabilities for Site-Wide AdministratorFirst, Next, Nice  
Capabilities for Registered Community MemberFirst, Next, Nice  
Capabilities for Unregistered Casual VisitorFirst, Next, Nice  
Capabilities for User Class NFirst, Next, Nice  
Design Preferences   
Performance RequirementsPage loading times  
Technical Infrastructure Constraints   
Application Maintenance Plans / Resources   
Budget Through First Year   
DeadlinesSoft launch, full rollout, first business benefit  

Capabilities for Site-Wide Administrator. For this as for other user class items, list those features that are needed first (must-have to launch the service in any form), next (what you'd do if you had a little bit of extra time and effort available), and nice-to-have. One example for the site-wide administrator user class is the following:

First = publish / manage content 
Next = spam members with news/offers 
Nice = track activity at individual registered user level 

Design Preferences. If your organization has an existing Web site or sites you can probably infer their design style. If they suggest Flash, frames, a lot of JavaScript, you've got a potential problem and might want to point out that Google, Amazon, eBay, and the other successful Internet applications stick to a plain, fast-loading, easily understood design.

Performance Requirements/Expectations. Start by suggesting your own standards of loading times in seconds for the index page and more complex pages on the site. Let the client react to these suggestions. If everyone agrees on sub-second page loading times, that will make it a lot easier to kick out the worst user interface ideas, such as Flash introductions.

Technical Infrastructure Constraints. A small or medium-sized organization will generally have only expertise and staff appropriate for maintaining one kind of server. If you're not building the project on top of that server, you're implicitly asking the organization to spend $100,000 per year to bring in additional maintenance staff and/or push the new service out to a contract hosting organization. It is best to be clear up front about what will need to happen when it comes time to move the system into production.

Application Maintenance Plans / Resources. Who's going to look after what you deliver? How experienced is this person?

Budget. What is the total budget for hardware, software, integration, launch (including populating with content), training, and maintenance?

Deadlines. You'll probably use other tools to keep a detailed schedule. Use this worksheet to keep track of some high-level scheduling goals that both you and the client are working towards. Avoid the temptation of stereotypical technical people to think in terms of their own requirements and tasks. Your client and sponsor don't care about SQL. They care about the date on which full business benefit (FBB) is realized for this application, i.e., when is the system adding to profitability or otherwise contributing to organizational goals. Working back from that date and recognizing that one or two version launches will probably be necessary to achieve FBB, establish a public launch date. Working back from the public launch date, establish a soft launch or full user test date. Working back from that date establish a "feature-complete build" date on which the programmers are only testing and fixing bugs rather than adding new features.

Persuasion Plan. For each item in this section, if differences of opinion arise during initial meetings, document a persuasion plan. Here are some elements of the plan that should be sketched in this worksheet:

About the Project

You'll have more detailed project management documents than this section of the worksheet. Consider this a high-level summary of how things are going. Try to have as many face-to-face meetings as possible, supplemented by telephone conferences and email, always anchoring the discussion with documents and written schedules. At a minimum, try to do a face-to-face meeting every three weeks and a phone call every week. This section of the worksheet should be updated every two weeks and will serve to flag any major problems.

It's tempting to blow this off, but projects need to be managed face-to-face (at least occasionally) and in writing. These disciplines force you and your client to be honest and realistic with each other. You don't have to overdo it with endless meetings and thick reports. A meeting at the beginning, middle, and end will do just fine, supplemented by weekly phone calls. And the table below will be plenty to flag major problems. Review it at least once every two weeks.

Date of most recent face-to-face meeting with Client 
Date of most recent telephone meeting with Client 
Date of most recent face-to-face meeting with Sponsor 
Date of most recent telephone meeting with Sponsor 
Have engagement letter (see below) signed by Client and Sponsor? 
Current specs signed by Client and Sponsor? 
Have weekly update meeting minutes, signed by Client? (includes changes requested / agreed / under discussion) 
Estimated delivery date vs. committed delivery date 
Estimated budget vs. committed budget 
Client mood (unhappy to happy) 
Team mood 
Mood of the average user who has tried the application 

A good engagement letter covers at least the following subjects:


Try to schedule comprehensive project reviews every three weeks or so, ideally face-to-face. Notes and decisions from those reviews should be signed by both sides (team or team leader and client). Requiring a signature has a way of forcing issues to closure.

Assets Developed

In building a profitable business or a professional reputation it is important to learn from and build on experience. Here are some of the things that you can take away from a project:

At the midpoint of the project, write down what you're hoping to take away from the experience. At the end, write down what you actually did take away.

Return to Table of Contents

eve@eveandersson.com, philg@mit.edu, aegrumet@mit.edu