The truth is: we don't have a chrystal ball to tell us what we need to incorporate in an application to make it useful to business... so how do we determine what should be in scope for the next project? There are many different techniques for requirements analysis, but most start from a predefined thesis of what the client wants. That can be a recipe for failure because most of these wants relate to the short-term concerns that relate to what employees do today, that should be a subset of long-term needs that depend on where a company wants to be, and when it wants to get there.

You may think that this is just a case of semantics...         that would be a mistake!

The concept of I.T. applications as enabling technology for business development is not new: it is, in fact, a well established principle. What this means is that you can make everyone more efficient by giving people the right tools to do the job, and to do it well with as little overhead as possible. Once the tools are in place the nature of work becomes more or less cast in concrete and variability in how work is done will then be reduced dramatically. According to many definitions of quality this kind of process "maturity" is what we strive for in order to get consistent results.

Effective tools that have become established as process enablers help to keep people in line with the intent of the process. Even if the initial introduction met with some resistance, over time the tools become part of how we do things around here. In many cases that is good. In some cases that is very bad.

Imagine, if you like, a starting point of a process that does not work properly (or that is not as effective as it could be) that is nevertheless used as a reference for defining the business requirements to develop the enabling technology to make it more effective. To get to the point immediately, this kind of system does not improve the process, it makes the same poor process more efficient at producing poor results faster. That is not what we had in mind, but in many definitions of quality such a process would be rated as very mature. ISO 9000 does nothing more than to certify that the company performs consistently according to predefined procedures, it does not provide an opinion about the quality of the products or services provided using these procedures.

A critical part of any business systems & strategy analysis is to find out what in the existing process might be broken, what might not work well in the future, or what might not work in a changing competitive environment. People need to be challenged, procedures must be questioned, processes must be pulled apart, deliverables must be justified, all to make sure we are doing the right things before we consider doing things right. Above all, we must make sure that the enabling tools are adaptable to change.

What this means is that business systems & strategy analysis is a very intense and stressful effort, just what most people like to avoid. This is where PM4HIRE.COM can step in to help you establish the proper foundation for your next strategic initiative. Whether you call on us to take a project from inception to rollout or just to establish the business requirements for a project that you undertake yourself, we use the same techniques for eliciting business requirements that are based on business stakeholder workshops to establish these requirements starting with the strategic objectives of the business. Simply put, whatever we want to put in place must consistently support the effort of achieving your strategic objectives: business requirements must be supported by user requirements that in turn are supported by functional requirements to make it so. By definition the functional requirements must link back to user requirements that clearly support business requirements. Let's take a closer look at what this means to you and what tools we use to achieve this audit trail from detailed to high-level requirements to make sure that we implement the right solutions.

The essence of strategic objectives is that you need to have a good idea of where you are going if you want to have a hope of getting there. The goal of business systems & strategy analysis stops short of defining strategic objectives. The goal is to identify those strategic objectives that may benefit from business systems that can be improved, which can help us to justify what we will automate and how we will automate. We need to know what the prospects are of the business systems we try to improve. It does not make sense to invest in a business process that is being phased out if you can deploy your resources to concentrate on more promising processes. Any business requirements elicitation session must begin with the identification of the appropriate strategic objectives that influence how selected business processes or operations will be expected to transform according to longer-term goals that are often achieved in stages. Sometimes the immediate justification for new functionality is difficult to grap until you realize that it is a stepping stone towards a much larger objective.

Strategic objectives are closely linked to Program Management and they require portfolio tools that can give you a broader perspective of how you achieve strategic objectives by orchestrating successive tactical projects. As a part of a specific portfolio you can see what the program is intended to achieve, even as some of the individual contributing projects may be obscure. It is important to reflect that because often small projects get cut without the full understanding of what that does to the overall business development program. To get around this problem, each contributing project must inherit (within each part) the benefits justification of the whole program in order to establish the relative merit of undertaking that work.

The reason for defining the business requirements first is that you need to have a good justification for all the work that is to be undertaken. In general business requirements relate to what benefits may be derived from future automation, which is clearly dependent on the strategic objectives. This is often a sore point, since people do not always recognize what strategic objectives are. It is quite possible that it includes supporting an already established operation by introducing greater efficiency in process, in throughput, in quality, or in other attributes of how the operation is managed. Our job is not to question strategic objectives but to make sure all development activities are in line with the goals of these strategic objectives that provide the real value of the implementation project. Often the benefits of contributing projects are difficult to quantify, unless the benefits are related to the larger program scope.

As noted above, we need to recognize two classes of business requirements: some requirements are part of a specific project, while other requirements are part of the program within which the project is undertaken. In many cases only the project specific requirements are acknowledged, which leads to understating the project to a point that it might very well not get approved. Hence, it is better to be able to relate the project to the larger value that would be jeopardized if the go-ahead is not received, and for the technical staff to highlight how the project fits into the larger picture. You need to identify the nature of the global vs. local business requirements because the latter must be supported by user requirements and functional requirements. The project itself must be a supporting element of the global requirements.

The purpose of user requirements is that you need to understand how people have to perform their duties before you can devise enabling application systems. Each user will have different needs and you will be challenged to come up with a solution that satisfies the most people as much as possible. Users typically perform their duties in support of business processes that are aligned with the business requirements. Here is where you need to be careful: the scope of the project (or even the program) may not encompass all the user functions, certainly not with respect to secondary or ad-hoc users and/or stakeholders.

The intent of functional requirements is that you need to have a modular breakdown of the functionality in order to make it possible to document how each aspect of that functionality is supposed to work. Many user requirements imply some form of support process that simply must be explicitly defined to make it possible for a developer to implement the appropriate processing logic, or for a procurement officer to purchase the right COTS product to meet the collective needs of the users. It is absolutely essential that functional requirements can be traced back via user requirements to business requirements. Sometimes functional requirements are defined that highlight gaps in the business requirements, that in turn highlight how we may not have fully understood all aspects of an application. This is a critical part of the process, in order to make sure that nothing is overlooked.

The functional requirements must be supplemented with specifications pertaining to various aspects of the infrastructure and implementation technology chosen for the business organization. These are often called non-functional requirements such as the programming language, the database software, the hardware, the operating system, and the many other assumed prerequisites that developers keep in mind. Standards such as these tend to be predetermined for a business organization, and they may be changed as required to keep up with technological changes. These standards do not play a role in the business systems & strategy analysis that is intended to document the business needs, so that (in theory) the functional requirements can be static and combined with non-functional requirements from time to time to create a new application that is then current with the latest operating environment constraints.

PM4HIRE.COM employs the proper processes to make sure that the proper requirements get defined before a project is undertaken. We know you get one shot at getting the requirements right, and that the requirements you define will drive every aspect of software development or procurement in the project. We help you to formalize your needs and wants that are prerequisite to creating enabling tools that will further your business goals.