During this step of building the project management solution, you are going to look in more detail at the specific requirements of the system. You will start by evaluating each group of users who will use the system to get a good understanding of what they will use the system for. As you meet with users and look at their needs, you will be able to identify the specific requirements that need to be included in the solution.
Our solution is going to be built based on the requirements of three types of users. Each group will interact with the solution differently, and to ensure that the solution is as effective and usable as possible, it is important to understand the specific needs of each user group.
The project committee, in our example, is a group of users who are directly responsible for the strategic direction of projects within the organization. They provide oversight, direction, and approval for projects and are responsible for understanding how projects relate to the direction of the organization. They approve the start of all new projects and provide strategic direction for the completion of projects. While project managers work directly with the organization throughout the project process, they are also responsible for communicating status to this oversight committee.
In terms of our solution, the project committee would require the following level of functionality:
Ability to access a real-time summary for all projects, which includes the following items:
Scope
Budget
Schedule
Ability to review, as needed, the following items for a specific project:
Project tasks
Project calendar
Project issues
Project documentation
In our example, project managers are directly responsible for the day-to-day management of any given project, based on the scope, budget, and timeline. Depending on the scope of the project, a project manager might be responsible for only a single project or for multiple projects. Project managers are responsible for assigning and directing resources, as well as for reporting on project status to the various stakeholders.
In terms of our solution, project managers require the following level of functionality:
Ability to get real-time status on any of the project elements, including the following items:
Project tasks
Project calendar
Project issues
Project documentation
Ability to easily report on the current project status to the project stakeholders.
Ability to easily communicate with various project resources on project issues and tasks.
In our example, project resources are the people directly responsible for completing project tasks. They work together as a team and rely on each other to complete the project. Most resources will be assigned to specific project tasks, but in general the project is considered a team effort and will require a level of input from everyone as tasks are completed.
In terms of our solution, project resources require the following level of functionality:
Ability to get real-time status on any of the project elements, including the following items:
Project tasks
Project calendar
Project issues
Project documentation
Ability to easily interact with other project resources on any project components.
Ability to create additional project tasks for project team members.
Ability to easily communicate with various project resources on project issues and tasks.
Ability to easily update the project manager on project tasks and assignments.
So far, we have outlined three different types of users who will be accessing our solution, and we have identified the primary requirements that each type has for the solution. If we mapped out the relationship of users, it would look similar to the illustration shown here.
In this diagram, you can see a relationship between the three user groups. Each group works together in a slightly different way but is still part of a larger solution. As you look at building this solution, it is important that you understand the requirements of each of the user groups and how they are incorporated into the solution as a whole. Any solution that you build needs to address the requirements of all three unique types of users and still provide one consistent solution. The best way to determine how to achieve this goal is to spend some time identifying how the different users interact with each other. The following illustration shows the relationships between the different users.
This diagram provides a high-level overview of how the different roles are related to each other. This information will be used to help design a solution that best facilitates this relationship. Understanding how the solution’s users are related helps ensure that our solution includes these relationships in the overall design.
Now that we have identified the different users who will be working with our solution, it is time to look at the different types of information that will be stored within the solution. The following list describes the different items that have been identified so far:
Project summary reports
Project documents (this includes Microsoft Word, Microsoft PowerPoint, Microsoft Excel, and PDF files)
Project contacts
Project tasks
Project discussions
Project calendars
Just knowing the data types, however, is not enough for us to really understand how to incorporate them into our project management solution. At this point you need to take time to understand how each of the user groups works with the data. How do users currently create and store documentation and project artifacts? Doing this will help you get a clear understanding of each group’s current processes and any pain points they have with their current solution. The following table identifies the assumptions for the sample solution within this chapter. The table identifies the current information in our chapter’s example. You can see that we are assuming that various types of content are created differently for each group. Whenever Office documents (such as Word, Excel, or PowerPoint) are mentioned, you can assume that these files are stored within a shared drive or an organization file share.
Required Solution Data | Current Location |
|---|---|
Project summary reports | Excel and Word documents stored in a shared drive that the project managers and project committee members can access. |
Project documents (includes Word, PowerPoint, Excel, and PDF files) | Stored in various shared drives and network locations. Each project team determines the storage location and structure for its project documentation. |
Project contacts | Some teams keep an Excel document with contacts on a shared drive, while others use a contact list in Outlook. |
Project tasks | Each project team stores its tasks differently. Some use an Excel worksheet, some use a Word document, and some use tasks in Outlook. |
Project discussions | Most of the project teams had a hard time defining what a discussion included, but most agreed that all discussions about projects happened in meetings and were recorded in the meeting notes or happened through email messages. |
Project calendars | Each project team manages its calendar differently. Some have a shared calendar in Outlook, and some keep a calendar list in Excel or Word. In some cases, the project team relied on everyone keeping their own personal calendars up to date and had no team calendar. |
The process of looking at users and the data they are accessing during project work is now complete, and it is time to start designing the solution. Before we start the next phase, it would be good to summarize the information collected so far:
The business problem was reviewed at a high level to identify the key requirements for our solution.
The different users of the solution were identified along with their relationship to each other.
The different types of data and information that are used by the solution’s users were identified.
This chapter is dedicated to a project management solution, but the process completed to this point can be followed for any type of solution you are trying to create. Next up, you will look at ways to translate requirements into a working design.