- 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
Avoiding the Big Bang Project
Throughout the process of “selling” the Salesforce.com project, getting the budget, and allocating the staff, expectations are being set about all the problems that will be solved. During this process, expectations are being set about the schedule as well—and often a fixed date (usually the first day of a fiscal quarter) emerges as an important corporate milestone. Finally, management develops expectations about the nature of the deployment, usually focusing on a system cutover, where users switch from the old way of doing things to the new system. And almost always, all of these expectations will prove to be wrong.
This story is as old as the computer industry itself. You don’t have to believe me: Fred Brooks’ classic The Mythical Man Month described how the larger the systems project, the more likely it was to be late. Even better, the further a project was into its schedule, the more likely it was that increasing the staffing and investment would make it even later.
The classic complete-system launch, sometimes called a Big Bang project, just doesn’t work for software. It can work when there is military-style command and control: the Manhattan project, Operation Desert Storm, and the Apollo program are shining examples. But in business systems, it’s hard to find examples where a Big Bang was a big success. Businesses don’t have tight military hierarchies, and IT has a culture of trying to accommodate new business requirements during the project. This accommodation and tendency toward scope creep—particularly in software—is a poisonous cocktail. The Standish Group, an IT consultancy, published a series of studies that extensively analyzed failed IT projects. The Chaos Reports concluded that overblown requirements and overzealous adherence to large, monolithic deliveries were key warning signs of failed projects.
We’ll discuss this issue in detail in Chapter 4. For now, be aware that the most important thing the project team can do before any project work begins is to avoid three things:
- Fake, vague, or overstated requirements
- Infrequent project milestones
- Large, complex, monolithic project deliverables
Even if the project has been “sold” with a lofty set of goals and tight Big Bang deadlines, it is important to quickly move to a phased approach. This isn’t just because of the IT “laws of physics”; it’s also human nature. Put simply, change management and confidence building take time. For even small companies, reset executive expectations by making the following arguments:
- We all know what the desired end-state is going to be, and those goals have been agreed to. But until the project is fairly far along, we can’t know which problems we’ll find in our data, precisely how business processes need to change, or exactly what every user will need.
- Given this inevitable uncertainty, the best way to achieve our goals is to rapidly deliver a part of the project big enough to provide value to the business. This first delivery will give users a chance to learn the system and provide real-world feedback that will improve later system deliveries.
- Delivery after the first phase should be incremental, with each cycle providing a new element of value to the business. Having small, frequent deliveries makes it more likely we’ll have happy users and low risk while meeting budgetary and schedule goals.
In making these arguments, the trick is to find the right “cornerstone functionality” to deploy for each phase, paired with the internal constituency you want to leverage. This decision making will be profiled in detail for each phase as described in Chapter 4, but as part of selling the project you’ll need to establish the constituency for the first phase’s subsystem right now.
The best way to select the subsystem is to answer this question: Which system element could be deployed the soonest and deliver real value to a meaningful constituency? By producing a quick win, you earn credibility for the project as well as users for the system.