Building Blocks of a Successful Project Part 2 – Business Objectives

Initiation

There areĀ  certain fundamentals that need to be in place to increase the probability of project success. The second of these is to have well-defined Business Objectives. These should be established as part of the original Business Case for the project. It is surprising how many times I have seen these absent from an initiative.

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 we be able to cut costs or deploy those efficiency savings to revenue opportunities?

I will go into more detail on this topic when I address the Project Charter. Suffice to say for now that the main reason for having solid Business Objectives as a building block for project success is that it guides all decision making on a project. Whether you realize it or not, all of the project team members are decision makers, typically making many micro-decisions every day. The Business Objectives act as the beacon of light for these decisions. Any decision that will reduce or modify the impact of the Business Objectives must be escalated to the Project Sponsor.

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.