A very common area of focus we hear from organizations is the desire to decrease product Time To Market (TTM) and improve Business-IT Alignment. Projects are either running long or delivering a product that does not match the vision of the business– both resulting in significant increases of resource time and effort, and opportunity cost.
There are a number of strategies companies can invest in to address these concerns. An enterprise architecture and/or business architecture team can be created to promote a vision across the company, and align projects and programs to business needs. An organization may decide to replace the development team with an offshore, onshore or nearshore model to improve project efficiencies and/or communication between business and IT. One frequently used mechanism these days is transforming IT from a waterfall to an agile environment, which targets quicker releases and enhances business’ engagement with the development team through a product owner role.
Time and again we see the easiest, quickest and least expensive way to significantly impact both TTM and Business-IT Alignment is to invest in generating better requirements. As Standish Group’s Chaos Report indicates, some of the main causes from project overruns are unclear objectives, lack of user input and changing or missed requirements. Poorly written requirements, particularly if they are part of a “phone book” requirements document filled with thousands of system-shall statements, are not consumable, resulting in discrepancies between what the business wants and what IT delivers. Most companies that transition to agile and don’t adopt better requirements practices find that they haven’t eliminated the same project challenges they had before; they simply find out about those challenges a little faster.
We propose making a couple of adjustments in the way requirements are elicited and defined. The first is ensuring your analysts spend an adequate amount of time defining why a project is being executed rather than just diving into defining the solution itself– this enables scope control. The second is leveraging visual models in order to achieve better Business-IT alignment and enable better project analysis, thus reducing the number of missed requirements. A picture says a thousand words, and we find that we can get more feedback on our requirements from Business and IT stakeholders by reviewing a process flow than we can by stepping through a list of a hundred requirements.
As with any organizational change, requirements transformation can occur with investments made in People (training, mentoring, trained resources), Process (Requirements Methodology standardization), and Technology (Requirements Management Tools). The investments made in these areas can have a significant impact on the projects for any organization, and are much less expensive than transitioning entire teams to Agile or switching out the development teams.
