Requirements Analysis Using Event Response / Use Cases: Business/Project Objectives

Planning

If you search this site using the keyword “objectives”, you will see my prior posts on the importance of documenting your Business and Project Objectives, as well as how to properly define them. Those posts framed objectives in the context of the Project Management process. Having the objectives defined is also critical in the requirements analysis process.

Here are some of the key reasons for knowing your Business and Project objectives in advance of your requirements analysis:

  1. Ensure that everyone on the project team understands the project vision. There is a saying in the military that “no plan survives contact with the enemy”. That is also true for projects (where the “enemy” is usually time and resources). However, if everyone understands the commander’s intent (the “objectives”), then it is easier to change and adapt the plan. Conditions may make you unable to execute the original plan, but you are always responsible for achieving the commander’s intent.
  2. The Objectives guide everyone’s decision making. There are many decisions made each day on a project. They are made by everyone on the team, not just the management. Along with empowering people to make decisions, you must give them the tools to make the right decisions. Chief among those tools is making sure they know and understand the Business and Project Objectives.
  3. The Objectives are used to validate the Requirements Model. At the end of the first round of analysis, you will compare the results to the documented Project and Business Objectives. Do your requirements address all the deliverables in the Project Objectives? If not, another round of analysis is needed. Will the requirements achieve the Business Objectives? If not, understand why. Has your analysis revealed additional Project Objectives? If so, these must be addressed in your Change Management process in order to change your Project Charter.

In the next post I will define the Event Model, with subsequent posts addressing each element in detail.

Advertisements

The Project Charter – Business Objectives

Initiation

As stated in the post “Building Blocks of a Successful Project Part 2”, Business Objectives are the “CEO’s view” of the project. They should make or save money, take advantage of opportunity, respond to new law and regulations, or increase competitive advantage. They should be specific and measurable to avoid what I call “Mom and apple pie” objectives like “We will be more efficient”. Really? Exactly how efficient? Will be be able to cut costs or deploy those efficiency savings to revenue opportunities?

Why is this important? Because everyone on your project is a decision maker whether you acknowledge it or not. Every day of a project, many “micro-decisions” are made without asking for clarification as that would be very inefficient. People will make these decisions based on assumptions due to lack of clarity in the objectives. Clearly stating the Business Objectives will help everyone make better decisions by asking themselves “does this decision support the Business Objectives as stated?”.

Another reason documented Business Objectives are important is they create a measuring stick for the health of the project. At any point in the project the question “Are the Business Objectives still obtainable?” needs to be asked. If the answer is “no”, the project is evaluated as to whether it should continue or not. Many projects forge ahead even if the Business Objectives are no longer possible because “we have spent a lot of time and money already”. This is a concept called “sunk cost” and this fact is irrelevant in good decision making. If a project no longer offers a return on investment (ROI), there is no point in throwing more money and time at it.

At the end of the project and at regular, predetermined intervals,  the actual outcomes need to be measured against the original objectives. If the outcomes met or exceeded the objectives, congratulations, your project was a success! If the outcomes fell short of the objectives, you can consider doing the following:

  • Find the root causes and address them, which may mean spending more time and money if the ROI warrants it.
  • If the ROI for spending more time and money to correct the root causes is not positive you can leave the project deliverables in place and not make any additional investment.
  • If the project results are actually having a negative impact and additional investment will not help you may need to reverse the implementation (if feasible) to prevent further damage.

My advice is to spend as much time as you need getting the Business Objectives right. It is the most important thing you will do on a project.