#153: Part II Business Requirements

Playbook –

This week on CIO Playbook with Jeffrey Hurley, I am continuing our discussion on project management tools and approaches with Part II of how to develop your business requirements.

I mentioned in last episode that there are multiple layers to project management and often the project management office tended to over paperwork versus project delivery in their focus.I then walked you through a business requirements document that I prefer to use in my organizations. Finding that consolidating multiple templates and forms into a more concise document tends to both create a document that will get read by stakeholders as well as get the technology team to work sooner.

This week we are focusing on completing the last few sections of the business requirements and how to incorporate the document into your project management process. I will show how working with your project managers and business management using a business requirements document will improve communication and delivery expectations. Then we will look into what it takes to maintain a business requirements document and conclude with you incorporating the document into your next project.

Interface Business Requirements

Almost every system will have some form of interface with other systems. This could be for the entitlements and people access through to data exchange between source and destination systems. It is in this section of the requirements document that these interfaces should be called out.

Business Requirements Revision Log

Business requirements documents tend to be evolutionary and will have multiple revisions before they are signed off and sometimes they will have to be circulated for signature after a major revision. Therefore it is important that a document of this nature maintain a revision log so that older versions can be reviewed and readers will know which version they are reading and referring to in discussions.

Business Requirements Approvals

Finally the business requirements document should have an approvals section where key stakeholders will sign off their agreement to the business requirements. This sign-off can be simple and contain sponsors and leaders or a much broader list of stakeholders. Either way a project should not proceed without these sign-offs in place.

How do You Use Business Requirements

A business requirements document is a communication tool. The human brain has limited capacity to remember much of what is said. Therefore it is important to write down expectations and needs of a system to enable the various teams to be on the same page with the business objectives of the application being worked on.

Business requirements will provide a method for testing ideas on paper before investing in tools and technology that may not meet the needs of the particular business situation.

Does Leadership Use Business Requirements

Investment in information technology is not inexpensive and therefore ensuring all stakeholders understand what is desired from the system both in effort and benefits it is easily to approve the dollar spend along with maintain the support over a longer period of a major strategic project.

What Role Do Business Requirements Play in a Project

One of the greatest challenges to projects is scope creep. Business requirements with their in scope and out of scope sections will help reduce the challenge of scope creep by the nature of calling out directly what will be and won’t be completed. In addition the active management of document revisions will call out any frequent changes happening which will allow management to take a more active involvement in the change management process.

If a document is changing frequently then a project may have issues with ineffective requirements or a constant stream of new opportunities preventing an effective delivery and as a result impact the organization’s ability to meet its objectives.

How do You Maintain the Business Requirements

I find that requirements can be simply maintained in MS Word or MS Excel. I have seen numerous third party applications that can maintain multi-layers of project documentation meeting PMI, TOGAF, ITIL and other technology frameworks. I have found that while these frameworks are impressive, in their documentation, it is hard to incorporate them into an organization effectively without significantly increasing the technology overhead.

Thus I find that a source control system for the MS Word or MS Excel document will work fine for maintaining the various versions of the documents as they evolve over the life of the project.

In Conclusion

To wrap of this business requirements series I am hopeful that some of what I talked about in these two episodes will lead to you making a change in how you are looking at some of your project documentation. Consolidating the plethora of available documentation into a set of concise tools that will improve team and stakeholder communication and shorten the time it takes to move from analysis to delivery.

Let me know how you are using your business requirements..best of luck,

Notes:

Photo Credit: US Dept of Agriculture. “A Variety of Dried Ingredients.” Flickr. Yahoo!, 16 Mar. 2014. Web. 05 July 2015.

The post #153: Part II Business Requirements appeared first on Jeffrey Hurley, Global CIO, CTO.