I’ve been so fortunate to be involved in a lot of collaboration projects in my career.
For this post I’ll focus on 8 specific/selected projects that I’ve been part of in the last 10 years, which all have the same characteristics:
- intranet or collaboration project
- global reach, with Nordic headquarter
- thousands of users (largest one with 27,000 users)
- business critical processes (collaboration, project portal and/or communication)
- large renowned company in the pharmaceutical, engineering, energy, or manufactoring business
For the record: I’ve been on “both sides of the desk”, ie. both as company employee (working as project manager or programme manager), and as vendor (working as project manager, service delivery manager and consultant). The learnings cover both sides of the experience.
1. Clear purpose and well-anchored support in top management
Your project must have a clear purpose (a WHY), that fits with the business strategy. We need (a) to be able to explain every action, decision and feature in the light of the purpose and (b) to engage stakeholders, content providers, and end users in light of the purpose. Keep challenging the project owner and/or sponsor until this (the purpose) is in place. If not, then consider putting the project aside for some months.
Be sure to establish a business case (e.g. run/grow/transform the business; ROI; KPI’s and when to follow-up), and get someone to own it.
The project needs well-anchored support in top management, with one or more of the CXO’s, preferably the CEO. We need it to ensure proper inertia in the project, ie. as ambassadors and role models, and for taking the lead in the discussions on top level.
2. Talk to the stakeholders, dammit
Sorry for the language, but dammit, you need to talk to your stakeholders very, very often.
You as project manager must make this your top priority. Often the PM falls into the habit of focusing on features and functions, but this is not as important as the stakeholders. So often I have seen that proper expectation management is not established. Either the top management is surprised and stops/changes the project midway or right before launch, or the middle managers is a huge challenge to get on board. If you don’t spend time on this, you’re going to have delays, lower quality, or a smaller scope than you promised.
- your top management, project owner/sponsor
- your process owners
- your ambassadors
- your reference groups
- your communication, IT, quality, and HR department (and more from case to case)
- your project team
Observe the culture and adjust accordingly. Culture has three dimensions: Company culture, country culture, and age. Invest some time to map it. What is predominant, when it comes to making decisions, choosing features, planning the global roll-out, creating content? The company culture or the country culture? Does the age demography influence on how we engage the ambassadors?
Have a plan for engaging with them, often and intimately. And then do it. Dammit.
3. Mindset and change of behaviour
If we want people to collaborate, to take part in the intranet, to share information in the project portal, or to strengthen cooperation with our commercial partners: Focus on the *mindset*, not the tool. Yes, it’s a well-beaten drum, but still not taken seriously enough.
Too often we end up discussing features, details on the taxonomy, or the visual layout, rather than investing time on the mindset; missing focus on getting employees to take part, contribute to the solution, and changing behaviour. Even top managers will rather invest time in functionality than discussing mindset change. Everybody wants development, but are reluctant to change. We must change(!) that! Use the purpose and user engagement to address it.
4. Team is everything
A succes-factor is your core team, which should consist of 6-10 persons (“if you can’t feed a team with two pizzas, it’s too large” –Jeff Bezos). The skills, experience and collaboration within the team is a make-or-break for the project.
AND: Your team culture, social capital, eagerness to help and support, communication and openness should be part of the design of the team, part of the daily vocabulary, and part of the regular evaluation during the project. You can really make an impact here.
5. Adapt to change
Your project is going to take 6-12-18 months. Expect change to happen. Address it with your CXO’s, your project owner/sponsor, the stakeholders – and with the legal and procurement department.
Your project might be cancelled or speeded up. Scope will evolve (a nice way of saying, that we cannot promise that we deliver exactly what is in the original specification or contract).
We will learn so much in the process, that the feature list IS going to change. As long as we support and fulfill the purpose (see no. 1), this should be ok … as long as the stakeholders are informed.
And, use an agile project model like SCRUM.
6. The project is not over when it is over
Finally, the 2nd part of your engagement starts when the project has delivered the product, and we’re at launch and go-live.
Now the purpose comes to life, and users start to use the product. Have governance in place. A support organisation. FAQ. Information sites and guides for usage. Go educate the users. Be open to feedback and change requests. System Management is an explicit part of delivering a global intranet/collaboration product.
Measure the impact. Is the purpose met? Does the project deliver the promised result? Plan, do, check, act.
On the personal side:
7. It’s motivating
It’s fun and a great journey. The purpose of bringing the organisation together in a shared cause is highly motivating, and I use the story-telling at every occasion for motivating the team and the stakeholders.
It’s my passion, and I’d do it again.
Ping me for questions or such!