- Getting to Business Value
- Developing a Model of Your Customer Relationship
- Setting Business Goals
- Setting Requirements: Who, Where, What, and Why
- Organizing and Publishing Project Documents
- Prioritizing Requirements
- When Requirements Should Bend
- Knowing Your Boundaries
- Making the Business Case
- Quantifying the Return
- Developing a Straw-Man Schedule
- Avoiding the Big Bang Project
- Outsourcing
- Setting Executive Expectations
- Getting the Right Resources Committed
This chapter is from the book
This chapter is from the book
This chapter is from the book
Setting Executive Expectations
Executives have been trained to see a business case that’s firm and a schedule with a clear end-date. Unfortunately, large systems projects don’t fit that model too often. And Agile project management, which is designed to make quality deliveries of what’s really needed in the shortest amount of time, creates a frustrating uncertainty about exactly what will be delivered when. The project leader must bridge that gap.
The first step is to convince the executives that SFA/CRM systems and processes must be adaptable to evolving business needs, so they are never completed the way a building would be. The next step is to focus attention on the cutover (or “go live”) date, including the absolute minimum criteria that must be met to achieve this goal. Most significant SFDC implementations are replacements for previous systems, so it should be fairly straightforward to identify the criteria for the new system to be “good enough” to support the switchover. It is important to use terms like “good enough” or “acceptance criteria” to communicate that the system will continue to evolve after the go-live date. Some functional areas need to be only at the 80% level at cutover time to support the business.
As always, perfectionism does not pay. By focusing the discussion on what is really needed to support a given business process on a day-to-day basis, you can get realistic objectives and feedback on which tradeoffs could be acceptable at the go-live date. For example, it may be okay to manually approve orders for the first month of operation, so as to make sure that the automatic order approval rules accurately reflect your business policies.
The executives need to know that functionality will be delivered incrementally, and that their staff will need to play active roles in assuring quality over several phases. Executives also need to know when the key business processes affecting their specific departments will be done. Consequently, we recommend organizing the presentation of the schedule in two ways: chronologically, for the overview perspective, and organizationally, for each executive. Keeping the schedule in a spreadsheet (which can be generated from your Gantt charting tool) allows rapid creation of these executives’ views, as shown in Figure 1-4. In this view, many tasks are repeated so that each executive can see the impact on his or her specific organization without having to refer elsewhere.
)
Figure 1-4 Executive’s overview of deployment phases
One of the biggest challenges of setting executive expectations is the iceberg phenomenon: the toughest work in the project is in infrastructure and data cleanup that has no visible feature, no immediate “win” for any department. Most executives don’t have patience for these intricacies of the project, and the best way to talk about them is in terms of “laying the foundation” for the features they want to see. Foundational work typically continues throughout the project, and it’s often best to depict it during all phases. Even so, every single phase needs to deliver some interesting feature to at least one department, so the executives don’t become frustrated with the amount of effort expended on “invisible stuff.”