Every project manager has experienced it—a beautiful product with an unhappy client. To avoid getting sideswiped by a frustrated business driver and blowing their budget and timeline to smithereens, you need to clearly define product deliverables, and more importantly, you must make sure you know the client’s true priorities. The suggestions below don’t replace a full-scale technical analysis, but they offer a means to organize a client’s expectations of a project’s deliverables.
Moving from vision to blueprint
Somewhere between the vision and the blueprint, a miracle occurs, consisting of two things: obtaining an expressed desired outcome and confirming that this is the actual desired outcome. You can facilitate this task by taking an honest and hard look at what the software is expected to do in terms that are meaningful to both the visionary and the architect. The prioritization outline we offer below provides a medium for accomplishing this. First, however, you must identify the correct person to participate in the process.
Project driver participation
The project driver is the person with the most influence over the determination of a project’s success or failure. The project driver may be the actual client, an account executive, or even you, the software designer.
It is important to single out the one or two people who are literally driving the project rather than rely on a group consensus. Too many cooks, as it were, shift a project’s priority focus based on individual experience. Only people with the big picture in mind should be asked to an interview.
The best time to interview the project driver about what he or she wants to accomplish is after the deliverables have been defined and before the requirements have been established. That way, the deliverables are fresh, but the technical specification has yet to solidify. To start the interview, you need to review the priority options listed on the next page.
To define project priorities, step through the following list with the project driver, going through the definitions and offering relevant examples.
- Conformity: Satisfy the project deliverables
- Security: Be secure from unauthorized access
- Performance: Meet speed requirements
- Reusability: Have components and functionality that are reusable as the system matures
- Extensibility: Have functionality that can easily be added to
Time, cost, and quality
- Timeliness: Be delivered when expected
- Budget impact: Be delivered at or below the anticipated cost
- Reliability: Operate consistently and without failure
- Consistency: Perform in a visually and logically consistent way
- Polish: Meet expectations in terms of professionalism, smooth operation, and visual and logical detailing
- Durability: Continue to be effective throughout its anticipated life
- Integrity: Maintain the integrity of business data and enforce business rules and other validation and verification requirements
Procurement and human resources
- Usability: Be easy to learn, understand, and use
- Work impact: Provide an acceptable working environment for direct users
- Technology: Use technologies that are familiar to the developers and users and that adequately meet the solution’s needs
- Staging ability: Have functionality that can reasonably be rolled out to a live environment in stages, as features are completed
- Portability: Easily be migrated to another hardware or software environment
- Interoperability: Function without affecting preexisting systems
- Dependencies: Function with as few dependencies on preexisting systems as possible
- Efficiency: Use hardware, network, and other resources efficiently
- Availability: Have means for ensuring high availability and uptimes
- Maintainability: Be easy to maintain and correct
- Supportable: Be easy for help desk, MIS, and other technical users to support
- Flexibility: Be adaptable to changes in functionality and resources
- Fault tolerance: Gracefully handle error conditions and environmental anomalies that should reasonably be anticipated
- Robustness: Include provisions for a fully mature solution, including considerations that may create overhead and not be visible to the end user
- Recoverability: Be easily recovered in the event of a failure
- Accountability: Provide capabilities to audit its operation and review key operational events
- Reporting: Provide a means for obtaining usage, functionality, and performance information
- Documentation: Include documentation regarding how it is constructed, deployed, and used
All the priorities listed here pertain to both the business needs addressed in a solution and the technical requirements of the system. Note that in using this list, some priorities are mutually exclusive and may require a technical explanation. For example, if security and accountability are top priorities, performance and work impact may be affected.
Once you’ve developed a familiarity with the terms on the previous page, ask the project driver to order them in the following categories:
- Level 1 (highest priority): This should include five of the 30 options.
- Level 2 (high priority): This should include six options.
- Level 3 (medium priority): This should include eight options.
- Level 4 (low priority): This should include six options.
- Level 5 (lowest priority): This should include five options.
Assist your client in ordering the priorities at each level. If consistent with your company’s practice, include two signature lines on the document—one for the project driver and one for the architect.
You may not agree with the level of priority assigned to each option. Talk through differences, and make sure you understand each other. Remember that you both have experience the other could benefit from.
Setting priorities creates metrics of success and manages client expectations. Additionally, the project driver sees that their best interests are being addressed, while the architect gains crucial information about the system’s desired goals. This process can help you understand the motivations behind the project and allows you to defer a tough decision to the appropriate person.
Once you and your client have completed the process, you’ll update the software requirements to reflect the outcome of this interview, and your project will have a stronger sense of direction and greater chances for success.
Using this prioritization technique will improve your insight into any solution and facilitate requirements definition and development scheduling. It’s also an easy way to break through any language barriers that might exist by laying out definitive goals on paper.
Prioritization allows you to incorporate architecture direction from an educated standpoint. Applying the process above takes some of the guesswork out of knowing what the client really wants. While it will never replace the need for in-depth, technical investigation, prioritization will improve any project’s chances of success.
How do you manage clients’ expectations? Drop us an e-mail or post a comment below.