Business Vs IT Business Requirement

Information technology professionals describe requirements first in terms of system requirements. These are the technical specifications of hardware, software and networking systems to support business applications. To produce accurate and reliable assessments of these and other information systems requirements, we need to understand the business requirements first. Information technology can make dramatic contributions to productivity growth. Misaligned requirements can lead to expensive disasters.

The more that IT leaders and analysts can learn about the business, the better. Start at the top with the business context. The context includes key foundations such as the purpose or mission of the business. It also includes the business strategy with regard to markets, customers, products and services. The next element is the management of the business including goal setting, metrics, and leadership style. Finally, the business context includes change management processes and communications.

Collectively, the business context serves to filter ideas, decision-making and the support structure to execute the ideas. It further serves to define how work is performed in the company and, as a result, how information is managed. The purpose or mission of the business clarifies the raw potential of the business. Think of ideas like ore, which is raw material that has a higher value in the context of a purpose or solution. The mission aligns all of the energy and effort of the people inside the company to achieve a common purpose.

In addition to learning about the business, effective IT leaders also learn the language of their business counterparts. Learn to bridge the communication gaps between business processes and functional models, and information flow and system requirements. Learn to adopt the business leader’s definition of a business problem and desired outcome to guide the development of process maps, modules and detailed requirements.

Finally, to connect with the ultimate value to the business, learn to connect information systems requirements to business outcomes, as expressed by business management. There are only two critical desired outcomes to any business, increased sales and increased profits. All of the other measures in the business support these two critical outcomes. IT leaders must align every IT project not only to the critical outcomes but also to one or more of the measures that contribute to them.

Examples of these business measures include:

• a measured reduction in response time to customer issues
• a measured reduction in the cost of technical support
• a measured decrease in cycle time; a measured increase in sales performance and closure rates
• a reduction in the time to deliver products or services
• a measured cost reductions to production including the cost of products, people, suppliers and time.

In designing solutions to business process problems, begin with the business requirements first. Determine whether the proposed solution will produce the desired business outcomes. Make design choices that lead to specific outcomes and measureable business improvements. Link investment needs to these business outcomes. In other words, “follow the path to the money”.

Create a believable roadmap to deliver business results in measureable phases. Large monolithic projects with multi-year development cycles face the greatest risk of cancellation, as the business grows weary with the financial outlay for no perceived return or improvement. Finally, to gain the confidence of the business leaders, share the technical knowledge, experience and project management discipline of the team that will implement the system.

Posted in Uncategorized | Comments Off

The Benefits of Documenting Business Requirements

Recently IT projects tend to underestimate the benefits of investing in developing comprehensive business requirements. Partnering with the business units upfront to define business needs has been proven to be the key to the success of an IT projects. You need to “know” what your business units “need” before you start building on the solution. On the contrary, common practice is that once the project is approved, all team members are eager to embark on the implementation of the solution.

We have all heard the usual: “… we all know what needs to be done, the business does not have the technical resources or knowledge for defining the requirements, everyone has developed projects so why the overhead of defining requirements, it is a waste of time etc etc.”…

One political strategy is pre-partnering. Clearly and comprehensively identifying user specifications and system requirements is key to project success. A thorough quality planning process (requirements gathering) is a critical success factor that is rarely given enough attention. One of the biggest reasons why IT projects fail is because project teams do not spend enough time in the trenches with front-line users,… To do this effectively, project managers must cultivate strong relationships between the IT project team, users, and stakeholders to ensure user needs and expectations are under constant focus and review. Source: Richard D. Lang [Project Leadership: Key Elements and Critical Success Factors for IT Project Managers]

In my view the five key benefits to having good and comprehensive business requirements are:

1. Better communication: Improves communication between team members and business owners through a formal requirements management planning process and offers a formal process for proposing and managing changes to requirements. It is an effective method of keeping stakeholders involved through the project lifecycle including design reviews, user acceptance testing, and deployment.

2. Lower cost: Significantly decrease costly rework and lowers project. Cost is managed reducing or eliminating unnecessary features and identifying significant flaws at the earliest possible time rather than after the system has been deployed.

3. Higher Value: Deliver higher value to the business. Clear definition of business objectives keeps the project team and stakeholders focused on delivering the value the business expects. Effective prioritization helps the business deliver real value, satisfies customer needs and enables the project team to fully understand and meet the needs of the customer as well as identification of missing requirements, ambiguities, and errors. It gives the opportunity to generate real improvements to the business units, not just change.

4. Lower Risk: Requirements significantly reduce the risk of project failure and provide the means to more accurately estimate timeframes and work estimates and control project scope. In addition to defining the scope of the project, the requirements document allows the project sponsors and board to clearly define and agree on what will and will not be delivered and what is expected from the successful completion of the project. It is like a “contract”, a formal agreement between the “client” and the project team.

5. On-time and quality: Deliver projects on-time. Provide the method for controlling and prioritizing requirements used to define accurate project schedules, underline the actual scope of the project and limit the probability of scope creep during project implementation. This allows for more accuracy in estimating timeframes and work estimates.

Alignment of requirements to business needs:

In order to maximize the benefits of requirements it is essential to remain aligned and keep the requirements updated during project implementation as there are many factors that may divert the defined requirements from the original. Project managers cannot afford to deliver in isolation; they need to be continuously involved with the business units and stakeholders to ensure that both business needs are kept aligned to the project delivery. Periodic reviews of requirements during the lifespan of the project ensure that the requirements are aligned to the continuously changing business needs.

On a final note, requirements will not only deliver business benefits that will be achieved by the project implementation, but will also considerably reduce cost, time and improve qualities which are the three main elements of IT project success.

Posted in Uncategorized | Comments Off

Are Business Requirements Important in IT Project Implementation?

Information Technology Projects within large organizations are frequently started in response to some business need or business failing. There is a tendency in organizations to seek funding and approval for project implementation through proposals based on high-level business needs. Usually proposals are attractive, inviting in appearance and are laid out in the form of a statement of work. They focus on the needs and objectives to be met and put emphasis on the persuasive factor of getting the project approved with the intent of “selling the project.”

A common approach is to proceed with the project implementation based on “the solution only” by defining the required resources, plan of action, deliverables, timelines, and estimated costs. The critical part of documenting business requirements is omitted and a brief list of very high level requirements is inserted to obtain funding and approval.

“The three major reasons that a project will succeed are user involvement, executive management support, and a clear statement of requirements.” “Opinions about why projects are impaired and ultimately cancelled ranked incomplete requirements and lack of user involvement at the top of the list.” Source the Sandish Group report: Chaos.

The main goals of documented requirements should be to deliver value, reduce time and cost, increase satisfaction and achieve success. In my experience, the three integral aspects that are necessary for the success of projects, but that are often missed out or not detailed enough, are:

1. Benefits and business value:

People lose focus of the project’s benefits and sponsors do not commit to measuring and achieving the defined benefits. It is very difficult to achieve business value if there is lack of commitment to attain the defined benefits. The benefit statements should be clear, concise, and quantified.

2. Detailed business requirements:

Documented requirements are Important!!! In order to align the solutions for delivery of business value, the business requirements must be captured and the solution must be managed to meet them. In my opinion business requirements should be S.M.A.R.T., namely Specific, Measurable, Achievable, Results-focused and Time-bound. Furthermore the solution should be designed to satisfy and comply with organizations enterprise architecture.

3. Documented quality assurance processes:

The lack of detailed requirements creates a huge problem for the Quality assurance team that is expected to ensure the quality of the project as a whole. The quality assurance team needs to have the means to compare what was delivered, to what was required. The more detailed the requirements are, including what is the proof of success, the more likely quality could be achieved.

Findings from surveys of over 100 companies in Keith Ellis’s report: “The Impact of Business Requirements on the Success of Technology Projects” determined that “Companies with poor business analysis capability will have three times as many project failures as successes. 68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. In fact, 50% of this group’s projects were “runaways” which had any 2 of: Taking over 180% of target time to deliver; Consuming in excess of 160% of estimated budget; Delivering under 70% of the target required functionality. Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects. Over 40% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization. The vast majority of projects surveyed did not utilize sufficient business analysis skill to consistently bring projects in on time and budget. The level of competency required is higher than that employed within projects for 70% of the companies surveyed.”

One must always remember that people in different roles will view the project from their own perspective and will not always see the bigger picture. A consolidation phase of requirements analysis needs to be done to look at these different perspectives and present an overall holistic best solution.

In FAO gathering business requirements is performed through brainstorming sessions with the business units and/or defining phased deliverables to be used as prototypes. The Information Technology Division in FAO has put in place mechanisms for ensuring Quality Assurance involvement in all phases of project implementation, from the project inception to project closure phases. In addition, emphasis for all IT projects to measure benefits and liaise with our business units to develop detailed business document requirements has become a prerequisite to project approval. In 2015 the IT division will measure the rate of improved project delivery due to increased business requirements definition.

In Karl E. Wiegers presentation, the “Cosmic Truths about Software Requirements” the following points are some key points to remember:

If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project; Requirements development is a discovery and invention process, not just a collection process; The interests of all the project stakeholders intersect in the requirements process; The first question an analyst should ask about a proposed new requirement is “Is this requirement in scope?”; The requirements might be vague, but the product will be specific.

On a final note, as considerable resources in terms of people and money are used to deliver what is actually needed for the realization of the expected business value and objectives, good business requirements are instrumental to avoid failures and complete successful projects.

Posted in Uncategorized | Comments Off