The Wall of Fire – 01 – Business requirements

In a pre-sales environment or an enterprise that empowers its own staff, the translation of business and strategic objectives into technical solutions is paramount. These can be such aims as to isolate customers, enhance stability, reduce cost, attain or maintain compliance or simply to meet an audit recommendation. These objectives are what allows the development of quantifiable specifications.

Business objectives are generally derived from a corporate strategy. This strategy is generally signed off by board members, stakeholders, and/or upper management. A corporate strategy defines an objective in which business will achieve a desired future with a deterministic outcome. With my company being public facing I can list ours. ESTA four focus pillars on which business works are derived – Efficiency, Sustainability, Collaboration, and Continuous Improvement. From this programs of work and subsequent projects are aligned.

Another huge driver for many corporations is compliance. Sarbanes Oxley, HIIPA, PCI-DSS just to name a few. These compliance frameworks ensure a plethora of standards are met in accordance to law. This ensures that those who are compliant are achieving a pre-determined benchmark. Depending on who you ask the rapport for these frameworks is different. If you are in one of these environments or consulting in one, a thorough understanding on the main checks and audit points is a good investment of time. This will allow you to understand constraints on work undertaken – and this leads to the next point.

Constraints are abound in all projects. It is rare near on never that a project has no constraints. It is important to gain a strong sense of clarity of these constraints early on as these generally are distilled into metrics for success. Some are physical, others are existing, there is internal policy and external policy, and it is good to know that some, one, or all of these could be contributing constraints. The better you interrogate the clients constraints the easier it will be to work on a technical solution. This will aid in minimising the rework associated with missing a constraint later on.

Where there is constraints there are assumptions. What befalls many who approach a project is not defining clearly the assumptions that you make. It needs to be articulated and communicated to stakeholders the assumptions being made that have guided your work. As you progress in early design phases clarifications can and will occur. This is a good thing. The more information a client can provide the better clarity you can obtain. This is along the same thinking as constraints. It allows you to begin transcribing a technical solution to meet the business requirements earlier with less rework.

A customer also will have pain points – long-term pain that has been accepted as a part of doing business. Identifying these paint points can be quite easy.  It can come about from general conversation and nuances in meetings. Little comments here and there can be potential opportunities to help solve additional problems. This is where the term ‘Nice to have’ comes into play. There is also the small little thing that has niggled the customer for a long time. Something small like export a report in a certain format, little widget here, or empowering the corporate environment to achieve mobile working. Little gains could be made inside the existing projects framework or it could be achieved inside another project or program of works.

Once you have clarity in this regard you will find that your best ally is your understanding of the business drivers. Understanding constraints and assumptions clearly allows you to work quickly and streamline the process to start developing the technical specifications.

Leave a Reply

Your email address will not be published. Required fields are marked *