The one thing that has been consistent on almost every project I’ve worked on is how easy it is to lose sight of the business objectives of a project once things get hectic. When a project starts getting tough and problems arise, most teams tend to focus on immediate deadlines and short term goals, and push the business objectives off to another day. As deadlines approach, the pressure builds, egos are challenged, and some team members spend most of their effort covering themselves from blame.
The problem is, this is when you need your business objectives the most. They provide requirements traceability, and are what will drive the hard decisions about what features are absolutely required and whether deadlines need to be pushed. Too often, these decisions are made based on past estimates and saving face, rather than truly looking at what needs to be delivered to meet the objectives of the project. As hard as it is to do, you need to drop all previous expectations, egos, and fears, and embrace the project’s business objectives as the key decision metric.
Your business objectives are where fantasy meets reality. Ignore them at your own risk. Launching a product that doesn’t achieve the business objectives will not benefit your business. Hitting a deadline is not valuable unless the product actually achieves what it was intended to in the first place. Now there are certainly some times where intermediate deadlines are helpful in measuring progress, even if the business objectives are not achieved right away. However, the objectives still need to be in view when you set these intermediate deadlines, to make sure that the project doesn’t end before they are achieved.
How do you prevent losing sight of your business objectives when the going gets tough?
First, you need to have some. Many projects fail right out of the gate by not having mutually agreed upon business objectives before any work begins. Get your BOM developed early and reference it often. (take a look at the example to the left)- Second, you need to constantly remind the team of the business objectives. They are not meant to be agreed upon and then forgotten. The longer a project goes, the more you need to reinforce the objectives with the team so that they do not lose sight of them. The business objectives model should be one of the first in your ever-evolving BRD, so it can always been seen and referenced.
- Last, they should factor in to all project decisions. Should we move the deadline? Should we hire more resources? Should we launch the product? Should we add or subtract features from our scope? None of these questions can be answered correctly without using your business objectives as your guiding star.
The great thing about maintaining a focus on the project’s business objectives is that you will not be surprised if they are not achieved. By constantly questioning their validity, you can figure out much earlier what results to expect from the project, and change course every time the business objectives seem unachievable. This may result in canceling projects midstream or creating entirely new unexpected projects late in the game, but in the end those actions are what will make the project a success, and achieve the results that everyone has been working towards all along.
