Claudia Eggers October 23, 2020 Project Management
The business requirements state what is required but do not specify how the deliverable will actually work. So in many projects with a tangible and technically sophisticated deliverable, it is very common to produce additional documentation about the look and feel of the end product. The functional specification describes not only how the end product will look but also how an end-user will actually use it and what the user-experience will be like. This document should contain sections that specifically relate to each of the requirements in the business requirements document so that every functional item can be tracked back to an original business need.
The business requirements document should accurately, and in detail, describe the purpose of the project. It states what is needed to achieve that goal i.e. what is in-scope, what is out-of-scope, any assumptions that have been made, any constraints that have been imposed and expected timescales. The document will form the definitive description of the aims of the project and, as such, can be used to manage the expectations of the stakeholders. It will also include acceptance criteria that will ultimately be used to judge whether the project was a success.
Among all the tools at our disposal for managing projects, checklists are perhaps the simplest and most productive means of building consistency in work practices. Checklists are useful in almost every field of human endeavor, and in particular where repeatability and systematic action drive performance. Yet they are still much under-used in the planning and managing of projects.
Project Managers are all too familiar with the project triangle. We know we can shorten a schedule by either (a) reducing the scope of the project, or (b) adding more resources to it. Unfortunately, management either has not seen that triangle or, more likely than not, simply chooses to ignore it. Consequently, Project Manglers who are more interested in pleasing upper management than keeping honest have come up with their own universal algorithm for shortening project schedules. Take the number of days that need to be cut from the schedule, divide it by the number of major milestones, and then deduct that number from the duration of each milestone. In other words, if a project comprising of 4 major milestones is estimated to last 6 months, but you need to reduce it by one month, you`d take 20 days, and divide it by 4. Take the answer (5), and deduct it from the duration of each milestone. And voila! Works every time.
Projects tend to slip for two reasons. Either Project Managers do not account for derivative activities such as vacation days when planning the overall project schedule, or they simply succumb to the pressure from management to compress the schedule. Now, present this schedule to the management team, and 8 times out of 10, the feedback you will get is "that`s too late". Eight times out of ten, you will be asked to revise the schedule and shorten it.
One of the tools you can use to get things structured and organized is the "Project Checklist". This checklist is a roadmap to setup and put a framework around the project before it gets started. Each PM has their own style and set of tools, but if you are working on building your own toolbox, the project checklist is an important item to have when defining the project itself.