A surefire way to let business drive IT projects

I’ve been thinking a bit about good methods to help the business (referred to as anyone that’s not IT) drive IT projects.

So far the method I’ve observed goes along the lines of:

1. Define the problem. Sounds like an obvious step, but in IT we’re all too keen to jump to solutions. A problem isn’t that we need an ERP or a CRM system, any more than not having a hamburger is a problem. The real problem is you’re hungry. Or for the first two examples, you want to manage the resources of an organisation efficiently, or you want to track all your interactions with your customers across multiple communication channels and plan marketing campaigns.

With the problem defined we can move on to…

2. Goals. Goals are visionary statements that frame any potential solution. Think of them as solution boundaries, where the solution must sit inside. A solution scope I guess. One could be more concise information for managers. These goals are intangible and immeasurable in the sense that it’s difficult to know if you’ve achieved them, but without them your solution might not fit into the strategic direction of the enterprise. No point coming up with a mobile solution if there’s no need for it.

3. Business objectives. These are finite measurable objectives that sum up how we know the problem has been solved in concrete terms. 100% of senior management reports come from the data warehouse. Customers will be able to purchase items from mobile devices. All absolutely measurable. No ambiguity, not for the business who can say that these objectives if met will meet the current needs of the business, nor for IT and the vendors who have no wriggle room in terms of what they’re delivering at the other side. As you can see, scope at this point if already defined, and while things could change within the boundary, if work doesn’t directly support the solving of the objective then it shouldn’t be in the project.

4. Functional use cases. The creation of these further tighten your scope and clarify exactly how people, process, and technology will change to meet the business objectives. Simple use case diagrams are great for communicating with the business the functions and processes within the solution, and we haven’t even talked any technology yet. After all, the solution could be solved by just a process change. Once all the functional use cases required to meet the business objective have been agreed to by the business, the scope is effectively defined. Then these use cases in the diagram can each be turned into fully dressed use cases with the standard process, exceptions, inputs and outputs, and all information a good use case should have. An example could be Load Information or Create Campaign.

5. Business requirements. With our functionality defined and processes sorted, we can think about what technological requirements are required to achieve the use cases. Creating a campaign will require software that has the ability to create a campaign. But we’re not focusing on a specific technology, and so the business requirements must be technology agnostic, and not just written as a laundry list of features of a particular software suite you have in mind. Because that would still be jumping to a solution ahead of time.

6. Solutions architecture. This really defines the non functional requirements of the solution, and is likely to start formulating a solution to meet the objectives. This would include aspects of solution analysis and design, and takes in the input of business requirements and comes up with a solution design. Sure some of the implementation gaps may not be filed, but by this point in time a solution had now been defined and can be traced all the way back to the problem.

From here there’s the normal software implementation life cycle, including change and release management procedures. By following this process we can ensure that we’re solving business problems in a clearly defined traceable manner that the business can understand and accept.