Requirements Analysis Using Event/Response And 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.

Note: My Kindle book “Project Management For The Real World”, is available at

https://www.amazon.com/author/lettera

The Project Charter – Project Objectives

Initiation

In the previous post I defined and discussed Business Objectives and their importance. Project Objectives are very different from Business Objectives. I have seen Project Charters with the two types of objectives mixed into one objectives section and I find it very confusing. I recommend placing Project Objectives in its own section.

Project Objectives should satisfy the following criteria:

  • Produce a product, service or result that survive and are maintained after the project is over. Some examples of this are (1) a new business “Standard Operating Procedure”; (2) new software installed that meets all of the acceptance criteria.
  • Each Objectives should have a definition of “done” that is agreed to by the Project Sponsor and the Project Team.

Project Objectives are important for the following reasons:

  • They define the scope of the major deliverables of the project
  • They will be used to define much of the activity scope of the project
  • Meeting all of the Project Objectives is one of the criteria for project closing

The combination of having well defined Business and Project Objectives will get your project off to a great start and help keep it on track. Take care to get these right.