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: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.
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) |
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.
| Topic | What the Client Wants | What We Think | Persuasion Plan* |
| Capabilities for Site-Wide Administrator | First, Next, Nice | ||
| Capabilities for Registered Community Member | First, Next, Nice | ||
| Capabilities for Unregistered Casual Visitor | First, Next, Nice | ||
| Capabilities for User Class N | First, Next, Nice | ||
| Design Preferences | |||
| Performance Requirements | Page loading times | ||
| Technical Infrastructure Constraints | |||
| Application Maintenance Plans / Resources | |||
| Budget Through First Year | |||
| Deadlines | Soft 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:
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 |
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.
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.