In my previous post, I discussed how Seilevel’s Business Objectives Model can help IT executives better align the IT projects that occupy their day-to-day activities with the business objectives of the organization as a whole. As I read additional literature on the topic, however, I came across another important point; one that oftentimes gets overlooked in the larger discussion over Business-IT alignment. In a 2007 entry in the Journal of Information Technology, Chan and Reich make the point well: “formal strategies [to achieve business/IT alignment] are often only implemented at the upper levels of the organizations, yet strategy is carried out on the front line.” In other words, aligning business and IT strategy at the top level is helpful, but only as far as it is put in to practice at the lower levels of an organization.
Once the business objectives for a project have been agreed upon by key project executives, it is imperative that these objectives drive the direction of the project from the initial project kickoff to its final deployment. Too often, projects with good intentions become bogged down by scope creep, resulting in cost overruns and delays. The Standish 2004 CHAOS Report, which surveyed 9,236 IT projects, found that 18% failed completely, and a further 53% were seriously late, over budget or lacking expected features. Even if the goals of the project are well aligned with the organization’s business strategy, successful execution of the project is essential to achieving those goals. According to the Standish Report, The top 3 causes of project failure were:
- lack of user input
- incomplete requirements
- changing requirements
At the heart of all of these causes of project failure is a disconnect between the high-level business objectives of the project and the detailed requirements of the project.
In order for business objectives to be employed properly, IT project leaders must communicate them to everyone on the project, from product managers to developers and testers. Project leads need to make sure everyone on the project understands what the business value of the project is and how the project is expected to deliver that value. As an example project, a developer spent time and effort to add a feature that would allow business users to change the default background color of the text editor to magenta and yellow because he thought it was a “cool feature.” While that may be the case, the feature added nothing to the value that the project was supposed to provide to the business. A greater emphasis on communicating the business objectives of the project to IT team members may have prevented such scope increase.
But how can we make sure that this occurs? At Seilevel, we analyze every feature for its contribution to one or more of the overall business objectives. If a feature does not help accomplish one of the project’s business objectives, there is a good chance that feature will be cut out of scope. On one such previous project, we cut 80% of features from scope that didn’t align with the stated business objectives, and still managed to deliver a $14 million increase in revenue. By closely considering the business value of each feature and it’s associated requirements, you can ensure that, not only is the project itself aligned with corporate business strategy, but also that the features of the project are aligned with the project’s business objectives. Prioritization of features against the business objectives of the project also prevents scope creep and allows the IT team to focus on those features that will truly add value.
Of course, prioritizing features against project business objectives in a reliable, quantifiable way is easier said than done. In my next blog post, I will discuss how we tackle managing this issue at Seilevel. Check back soon to find out more!