Project Definition

What’s up with the Project Definition?

The Project Definition is often your first deliverable. What goes into this document should be discussed with the client at the earliest opportunity possible. At the end of my second article, I’ve included a complete list of what I find essential. However, a Project Definition is not worth anything unless at least two items are detailed — the stakeholders and business process.

The first and most important thing is to identify the “stakeholders”. These people are usually department heads. The information for this document is collected via interviews with as many stakeholders as can be identified and the sooner you can begin the better.

I usually begin my stakeholder search by identifying the heads of those departments who have the problem I am trying to identify. These department heads usually have a lot to say about what they expect from this solution and are able to point-out the people on their teams who are knowledgeable of the process requiring rationalization. If the department heads don’t seem to know, then I usually ask who’s been around the longest.

It is important not to take every interview recommendation serious. This may lead you around the company interviewing people with no knowledge of the issues you are identifying.

Here are my interview criteria:

1. Which departments will use the solution I will ultimately recommend?
2. Who are the department heads?
3. Who are the most knowledgeable people in each department?

These guidelines have never failed me.

While writing the document, try to keep your text straight and to the point. People enjoy talking about how to do their job better, but they don’t want to waste a lot of time reading about it. After all, saving time is ultimately what your work is all about. Also, don’t include stuff like, “The system is required to be real fast.” Be specific. How fast? Check the web for the latest performance benchmarks in accordance with your hardware requirements and similar systems.

While you’re looking over the shoulders of the stakeholder, note how “useable” the system should be. If they are not very computer savvy, you must insure the system is easy to comprehend and designed to match, as closely as possible, their current workflow. Collect source documents. (The paper work the stakeholders currently use to do their work.) Usability impacts two important areas; the training you will later do and how well the solution you propose will be adopted by the stakeholders. According to the impact usability may have on these two areas, you may want to dedicate an entire section in the Project Definition to this subject.

This document sets the tone of the project, captures the most important issues and sifts-out the major stakeholders.

The next essential step is to identify and document the business rules.

Business Rules

Business Rules run the company. Gaining a quick and complete (sorry no short-cuts here) understanding of these rules is one reason why Business Analysts are so important to developing successful IT solutions. If the analyst understands the business rules and has documented them well, there is never a reason for a developer to interact directly with the stakeholder.

Outlining the information usually works well because it helps keep your thoughts short and enables people examining your document to easily find and note specific issues they may want to discuss. Here’s a brief example:

Feature film procurement process:


1. Department head fills out standard requisition form issued to them by the production account’s assistant. Department head assigns requisition request a predefined account code.
2. Production Accountant edits requisition codes and passes requisition form to the Unit Product Manager.
3. Unit Product Manager checks if requisition amount is within budget and if the requisition code is correct. Based on these criteria, and personal judgment, the Unit Production Manager approves or rejects the requisition request.
4. If the request is approved, the requisition is passed to the supplier by the Unit Production Manager’s Assistant.

Alternate One

1. Department Head goes directly to the Production Accountant with verbal requisition request.
2. Production Accountant assigns requisition the proper account code and passes request to the Unit Production Manger.
3. Unit Product Manager checks if requisition amount is within budget and if the requisition code is correct. Based on these criteria, and personal judgment, the Unit Production Manager approves or rejects the requisition request.
4. If the request is approved, the requisition is passed to the supplier by the Unit Production Manager’s Assistant.

Alternate Two

1. Department Head assigns requisition the account code and passes the requisition directly to the supplier.
2. The Production Accountant notes the account code and passes the fulfilled requisition to the Unit Production Manager.
3. The Unit Production Manager notes the account code and requisition amount.

As you can see this gives raise to all sorts of questions. Who creates these mysterious requisition codes? What do these codes represent? Who sets the departmental budgets? What happens when this budget is overspent? At this point begin to envision the system and its scope. This helps to identify which questions require an answer and which could be answered later. Additionally, keep the “who” and “what” questions in mind while you create this document. This will be a huge help when you begin work on your use cases.

Depending on the project scope and client’s needs, the analyst may need to add more detail to their Project Definition. In my estimation, here is a good outline for a Project Definition on steroids.

* Purpose Scope — Briefly answers two questions: What the solution should and should not do?
* Stakeholder identification — Who really knows the business processes requiring rationalization?
* Constraints — Detailed list of how the new solution could influence existing systems.
* Requirements which include:
1. Functional requirements — Detailed list of what the solution should do.
2. Usability requirements — Define how computer savvy the end-users should be to learn and operate the system. If the stakeholders are not very computer savvy, the system must be easy to use.
3. Technical requirements — Check the company’s security policy, how the network is managed, operating system and database platforms used now and in the foreseeable future, integration dependencies, client / server hardware requirements.
4. Support requirements — Identify who is going to train and assist the end-users after you are gone.
5. Workflow — I usually attach my workflow diagrams, discussed in the next section, as an appendix to the Project Definition if the deadline allows time.
6. Evaluation plan and performance metrics — With the stakeholders and technical staff, determine what defines success. The stakeholders usually focus on usability and response times; the technical staff usually focuses on integration and upkeep issues.

If done properly, the analyst will be the first guy in the door and sticks around through the deployment, insuring the client gets a solution that solves their problem.

Additional Resources

The requirements and format for a Project Requirements Document are not defined and regulated by a body like the The Object Management Group. To gain a better understanding the breath this document may have, I recommend reviewing other examples. Here are some locations that may help.
Wikipedia Article on Product Requirements Documentation
Wikipedia Article on Business Rules
Project Definition hosted by Spottydog’s Project Management Web Site


Here is my standard Project Definition document in various formats. Feel free to use the Word Document as a template.

Flash Paper
Microsoft Word Document

About Larry

Passionate, experienced Agilest with a love for Scrum and Kanban. Huge fan of Lean, Theory of Constraints and of course the Toyota Production System. Avid learner. Deeply influenced by the works of Jeff Sutherland, Ken Schwaber, Eliyahu Goldratt, Jeff Patton and countless others. Active in both the PMI and Agile communities in Southern California.
This entry was posted in Product Owner Stuff. Bookmark the permalink.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.