60 to 90 minutes
Explain the purpose of the activity and write it down on the board or mind map.
Then, ask the participants to imagine that enough time has passed and the key team members are assigned to the project, and that they can now use those people’s knowledge and their own facilitation techniques to create the Project Description.
To make it easier, we’ll work on the 5 main topics of the Project Description separately.
1. Purpose and expected benefits
Give them 5 minutes to document the purpose and expected benefits of the project. Ask the facilitators to paste their answers in the public chat box for everyone to see.
Most of the information is already available in the scenario, and it’s mainly a matter of formatting a brief explanation based on that. For example,
The purpose of the ArtoLibre@Artophile project is to replace as many proprietary software applications as possible with libre alternatives.
Expected benefits/outcomes:
- More compatibility with the applications used in the public sector
- More security and privacy
- Less software lock-in
- More environment friendly
- Less expense in the long run
To be accurate, the items above are outcomes rather than benefits, but it’s fine to list outcomes instead of benefits when the benefits are not financial in nature and are hard to quantify in financial or non-financial terms. Moreover, expected benefits must be prepared in program or portfolio management layers and only mentioned in the Project Description for alignment purposes; the project team is not responsible for planning them.
If your learners are familiar with benefits management, you can spend two or three minutes discussing the difference between benefits and outcomes, and how these outcomes can be quantified and turned into real benefits.
There’s a mention that cost reduction is a likely outcome, but not one of the reasons for running the ArtoLibre initiative. This means that it won’t be listed as one of the benefits/outcomes of the ArtoLibre initiative, but remind them that we’re working on the ArtoLibre@Artophile project, and there, the company may want to have cost reduction as well – it’s all up to their imagination. Indeed, having layered or overlapped initiatives is common, and people tend to mix them when composing their Project Description, so it’s a good exercise to see it here and think about this issue.
2. Expected cost and duration
Ask them if they have any idea about duration.
The scenario mentions that the government’s proposal is to run the initiative in 5 waves, with at least 6 months between each two go-lives. So, assuming that implementation of each wave is not longer than 6 months (which is probably the case), the whole project will last about 30 months. This rough estimate is fine at this point.
Explain that in a real world project, they may or may not have a budget for the project at this point. Let’s assume there’s no budget yet, and leave it blank for now.
3. Requirements and quality expectations
Ask them to spend 5 minutes in their group and prepare a list of requirements and quality expectations. Tell them that this type of information usually comes from outside the project and that their main responsibility is to collect, organize, and refine it. So, for the exercise, they need to put their user hats on (as specialists working in a company) and give their expectations.
When the time is up, ask each facilitator to explain one of their items and then go to the next team. After the first round is finished, go back and ask them to describe the second item, and so on.
The most common problem is that people tend to explain a certain product/output instead of a requirement/outcome. If there are any such items, pick one and work with the participants to see how it can be converted into an outcome-based item.
One of the items mentioned in the scenario is this:
The libre applications that replace proprietary ones are expected to be better than them or at least on the same level (whatever “better” means for the end users) – it should be an upgrade rather than a downgrade. When options are limited, minor downgrades are acceptable, but in cases where liberation requires a major downgrade, the proprietary application can be kept.
This is a good example of a requirement/expectation, but it would be helpful to describe what “better” means in Artophile.
Other examples:
- Our system and its content should be available from outside the company.
- Our old content should be accessible in the new ecosystem.
- Some of our clients will send us content with proprietary formats – we should be able to open and use it.
- Our system should be GDPR compliant.
4. A high-level description of in-scope and out-of-scope elements
Proceed with this section by asking them questions instead of having a group exercise. Selecting and implementing the software applications is clearly part of the project. What else do we have? Does it include training? Maybe, maybe not – that depends on how the project is defined, but it’s up to them to make it clear at this point. If it’s not part of the project, it’s a good idea to document it as out-of-scope to avoid future confusion.
Ask them whether they can come up with other things that may or may not be part of the project. Another example is conversion of the existing content – the existing content should be added to the new ecosystem (e.g., designs, emails, and letters). Should it be done as part of the project, or is it expected that the users do it themselves?
The main point is to think about the possibilities and make them clear at this point.
5. A list of stakeholders
Tell them what a stakeholder is (someone who has some type of interest in the project and has the power to impact it). Then give them 5 minutes to work in groups and prepare a list. Let them know that it’s fine to use their imagination and make up stories that create new stakeholders. Also, ask them to divide the stakeholders into project team members, internal members who are not team members, and external members. This helps them identify more stakeholders.
When the time is up, ask each facilitator to present their work.
The external stakeholders can be the public sector, the existing and potential clients, the suppliers, etc.
Every person and department in the company is an important stakeholder. However, they probably won’t list every single person, but create categories that cover every type of interest and potential impact; for example, architects, civil engineers, mechanical engineers, etc. However, in addition to that, some people may be listed individually because of their unique attributes; e.g., a certain manager who hates Linux and an engineer who was a contributor to an open-source project in the past.
Finally, the project team members are the sponsor, the project manager, user representatives, and IT experts (the internal ones as well as the hired consultant).
It’s common for people to just list titles or roles. This may be the right way for some stakeholders (e.g., generic external stakeholders), but it shouldn’t be the case if it can be avoided (e.g., project team members). So, if you see generic lists only, help them replace them with imaginary names, followed by project role and organizational role; for example: “John Doe, user representative, senior mechanical engineer”
Conclusion
So, at this point, we’re done with the Product Description. Give them 10 minutes to work in groups, make final adjustments, and combine everything into a simple text document (for online workshops) or a piece of paper (for face-to-face workshops) that will be their current version of the Product Description.
When the time is up, ask them to share their work with everyone without explaining it. You don’t need to give any comments at this point, unless you spot a serious mistake.