40 to 60 minutes
Explain the purpose of the activity and write it down on the board or the main map.
This is the first monthly cycle. Ask them to check their schedule and tell you which deliverables will be in progress during this month. The answer is the “new server”.
Extra scenario
Next, they need to detail the plan for the upcoming month. This detailing is at least partly technical, and they may not have the technical expertise to do it. This is a good opportunity to explain why they need to have the key team members appointed as soon as possible. Whatever the situation, tell them that they can use their own knowledge and imagination if they are familiar with setting up servers, and otherwise, they can ask you questions as if you’re the IT expert in the project.
This could be the imaginary expert’s explanation:
Well, we already have a few servers, but it’s a good idea to set up new servers to avoid potential conflicts. What I have in mind is a physical server with redundancy, and then a number of virtual servers on it, one for each of the services. The type of services we need depends on the applications specified in the various waves, but some of them I can name from the start:
- Email server
- Calendar server
- File server
- XMPP or Matrix server for messaging (probably)
In addition, we’ll need to have secure access to some of them from the Web, an automated backup system, a log monitoring system, a resource monitoring system, etc. Finally, our network structure is old and less than perfect, which may create a bad experience for the users, as we will be using the network more than before. While we’re working on this project, I would really like to improve our network infrastructure as well.
Exercise
Give them 10 minutes to work in groups and refine their plans for the upcoming month. Tell them that this may change the Project Description, Deliverables Map, schedule, and Follow-Up Register.
When the time is up, ask each facilitator to present their work.
Risk management
One of the things we expect at this point is a serious consideration of the last point in the expert’s explanation about improving the IT network. First, the expert is thinking about a risk, so, let’s document it in the Follow-Up Register:
- Cause: The IT network is old and less than perfect.
- Effect: It may not be fast or reliable enough, especially when used more intensively by the libre applications.
- Impact: Its low performance may be considered a problem for the libre applications we’re going to introduce and cause problems for the adoption of those applications.
- Response: Improve the IT network (?)
- Status: Open
- Custodian: TBD
Let them know that it’s essential for project managers to be looking for risks and documenting them for follow-ups. They should also try to expand conversations and look for similar risks whenever possible. Let’s assume that we’ve tried and no other related risk was discovered.
Change management
The other point about the IT network is that it wasn’t part of the project; i.e., it wasn’t included in our initial, approved Project Description. So, we can call it a change. Change requests, like risks and issues, are captured in the Follow-Up Register, and we already have an item for it, so, there’s no need for documenting it again.
Ask them who they think should approve or reject this change request.
Tell them that in general, it depends on the type of change. If it’s a small change with limited impact on project targets, the project manager can decide; otherwise, the project manager should escalate it to the sponsor. The sponsor is responsible for checking it with other people if needed, and letting the project manager know what to do.
The change in this scenario probably impacts the cost and duration of the project, and may also have an impact on operations in the company. Because of this, it’s almost always a significant change that should be escalated.
Let’s assume that we’ve estimated it will cost 2 Artopools and add one month to the duration of the project. We’ve reported this information to the sponsor and asked for their decision. They’ve approved the change. In that case, we can update the Follow-Up Register:
- Cause: The IT network is old and less than perfect.
- Effect: It may not be fast or reliable enough, especially when used more intensively by the libre applications.
- Impact: Its low performance may be considered a problem for the libre application we’re going to introduce and cause problems for the adoption of those applications.
- Response: Improve the IT network (as approved by the sponsor)
- Status: Closed
- Custodian: –
We also need to update the expected time and cost in the Project Description.
Adjust the plans
Now we have one extra element to add to our plan: the new IT network. Besides, there were extra details provided by the IT expert.
Their Deliverables Map may look like the following at this point:
- ArtoLibre@Artophile
- Infrastructure
- Servers
- New physical and redundant servers
- Internal services and virtual servers
- Automated backups
- Resource monitoring
- Log monitoring
- External services and virtual servers
- Email server
- Calendar server
- Messaging server
- File server
- IT network
- Wave 1
- Implementation
- Training
- Content conversion
- Wave 2
- Implementation
- Training
- Content conversion
- Wave 3
- Identification
- Implementation
- Training
- Content conversion
- Wave 4
- Identification
- Implementation
- Training
- Content conversion
- Wave 5
- Implementation
- Training
In the real world, you will show this to the experts and ask them whether anything is missing. The hierarchical structure of the Deliverables Map usually helps them fill in the gaps. For example, they may immediately tell you that firewall and VPN are missing.
- ArtoLibre@Artophile
- Infrastructure
- Servers
- New physical and redundant servers
- Internal services and virtual servers
- Automated backups
- Resource monitoring
- Log monitoring
- Firewall
- VPN
- External services and virtual servers
- Email server
- Calendar server
- Messaging server
- File server
- IT network
- Wave 1
- Implementation
- Training
- Content conversion
- Wave 2
- Implementation
- Training
- Content conversion
- Wave 3
- Identification
- Implementation
- Training
- Content conversion
- Wave 4
- Identification
- Implementation
- Training
- Content conversion
- Wave 5
- Implementation
- Training
If you have IT experts among your participants, they will tell you a lot more, and more refinements and adjustments would be possible – the example above is really simplified. Accept their expert suggestions, but keep it limited because it’s a project management workshop, not an IT workshop.
Similar details should also be added to the schedule, and their priorities or dependencies/order should be refined as well. Don’t go into too much detail when it comes to the schedule.
Deliverable specifications
Explain that another thing they normally do in this activity (as well as in A05) is to document the specification of various deliverables, which can be added as comments in the Deliverables Map (especially if it’s prepared as a mind map).
The specifications are the technical attributes, quality criteria, and such. This part is mainly done by collecting the information from internal and external stakeholders, and therefore, there’s not much we can do about it in a workshop.