Do you have your head in the sand about these project challenges?
Categories:
Benefits Management,
training,
Quality,
Risk Management,
Stakeholder Management,
Change Management
Categories: Benefits Management, training, Quality, Risk Management, Stakeholder Management, Change Management
| As much as we’d love to have everything working to plan, sometimes we can take some aspects of project management for granted. I wonder how many of these project challenges you have but you haven’t openly recognised within the team? I don’t want you to have your head in the sand, so below I share 10 things that you might be missing on your project. (I didn’t want to bury my actual head in the sand, so you got a photo of my feet buried instead! Not quite the same, I know.)
We might believe that stakeholders are reading our project comms, but are they really? It’s hard to tell, but if you aren’t seeing any action, or people are asking questions you have already answered in your comms, then they probably aren’t.
I expect it isn’t, even if it feels like it should be. People won’t turn up or won’t use the online training to teach themselves. Plan to have post-launch training support because your users will need it.
Hopefully they are, but as above, there will always be someone who says they didn’t get the memo, or couldn’t access the materials. Make sure you’ve got post-launch training in the diary as well, and do more change management activity and engagement than you think you should have to.
UAT is the one thing that gets squeezed in my experience. Add in an extra cycle if you can. It’s easy to take it out – not so easy to squash it back in if you do need more testing time. This obviously depends on your project – if you are doing something you’ve done a lot before you should have a high degree of confidence in your deliverables, but you might need more if you are working on something new.
It hasn’t! Make sure risks are constantly mentioned in all meetings, and that you are always listening out for what might be a new risk.
Team morale is something to keep an eye on. The team can get demoralised for the smallest of reasons, from a change not being approved to a reschedule for whatever reason. That negativity can spiral. Even if things are going well on your project, events outside the project can influence morale, such as a change in leadership, redundancies, an increase in BAU work or pretty much anything else.
We’d like to think the financial and tangible benefits are understood, but how well have those assumptions been documented? I’ve worked on a couple of projects where we think we understand what we are tracking, only to find that we can’t replicate the exact formula the finance person (who has now left) used, or some other difficulty. You should be able to answer straightforward benefits-related questions like ‘is this incremental revenue or total revenue’? So make sure you can.
There probably is, but people are too polite to mention it. You should dig for it! Some conflict is healthy so don’t worry about bringing it up.
Are you finding bugs in your deliverables? And more importantly, are you squashing bugs? What are your criteria for exiting testing and how does quality play into that? Ideally, you should have great quality measures, and be performing in line with those, but sometimes project teams get swept up in the desire to deliver and that means some lower-risk bugs are left in for now.
Are your project deliverables introducing technical debt? Are you breaking things elsewhere or for other teams, or introducing workarounds or degrading the solution for someone else? Sometimes your part of the world might be fine, but a process you’ve implemented ends up in many additional steps or a new report being needed for someone else. Check that you aren’t creating technical debt by accident – if you know about it, document it and have created it ‘on purpose’ as part of a stepping stone to a different solution, then that’s probably fine. Which of these might your project be at risk from? Let me know in the comments! |
Project initiation: Tips for starting off right
| Are you starting a new project? As we get closer to year end, we seem to be starting more projects that will (somehow) finish in-year! If you are kicking off a new piece of work, whether you’re delivering by year end or have a longer timeframe, here are some tips to consider to ensure you are starting off in the best possible way. Get the right peopleFirst, you need to understand the capabilities required to deliver the project. Then you have to make sure you have people with those skills (or people with the aptitude and time to learn them). It’s not just about the do-ers. You’ll also need a project leadership team (a project manager, sponsor, maybe exec sponsor and programme manager) who have the skills to lead and are empowered to do so. Create your CharterWhether you call it a project initiation document, charter or kick off document, you’ll want something in writing to document what you are doing and how. But the real value of this is in the discussion that you have while pulling together the content. The right conversations are essential to make sure the right stakeholders are involved, everyone is aligned on the objectives and the scope is clear. Set the tone for the teamWe talk a lot about culture and I’ve written about psychological safety before. Start as you mean to go on, so set your ground rules, working practices, terms of engagement up front. Make sure that anything that affects the delivery team involves them (so no setting project delivery dates without the people doing the work in the room). Set up your document repositories and communication schedules so everyone knows what to expect and where to find the latest information. Consider riskAs part of your project initiation work, you should be creating an initial risk log. But considering the impact of uncertainty on your project goes beyond that. Make sure you’ve got enough contingency in the plan, especially in the early days until estimates can be firmed up with more data. Make sure stakeholders know about confidence levels and be transparent about what you think can be achieved, so their expectations are managed. Sort out your governanceExec confidence comes from knowing the project is in safe hands. Governance might feel burdensome at times, but it ensures the right work is being done by the right people at the right time. Make sure you know how the project will be held to account, and what the success criteria are. Set up your peer reviews and stage gates. Book steering group meetings and regular check ins. Dig out your reporting templates. These processes will ensure that there is trust in the process and that leaders feel confident that the project can (and will) deliver. Setting your project up for success is crucial because those early days set the tone for how the work will be done. Spend a bit of time – and I know, you’ll have to negotiate for that as I expect everyone wants the work to have started yesterday – and you’ll have a greater chance of delivering successfully. Good luck! |
Tips for Knowledge Sharing in Teams
| If you’re role is anything like mine, sometimes being a project manager can be a little bit lonely. We don’t spend much time with other project managers, because our focus is on the team and the people we work with there. So how do project managers learn from each other? We’re great at learning from project experience: you’ve probably got retrospectives and project lessons learned meetings in the diary for the next quarter. But when do we get to hear what our peers are up to? Here are some tips for fostering a culture of knowledge sharing in project management teams.
If there’s more than one project manager in your department, chances are you have team meetings. Make knowledge sharing a regular agenda item. Have someone present about their current project. Or have someone share the top lessons learned from within a project. Have someone share about their experience of using a process or making a new connection in a different part of the business. Use Shu Ha Ri as a way of packaging up your lessons. Schedule project management coffee chatsSometimes it’s nice to have chats with your peers. This can work well if you haven’t got many project managers in your direct department, so you can’t invite them to a formal meetings, but there are others doing the same role elsewhere in the business. Build an informal community of practice. You don’t have to call it that, but you can set up a shared mailing list or have your own ‘directory’ of project managers across the organisation. Share resourcesModel the behaviour you want to see by sharing resources. If you’ve got particularly good feedback on a steering deck or a business case, share it with the team. Invite others to do the same, perhaps start a ‘good documents’ folder on your shared drive so that everyone can upload examples of docs that have worked well for their purpose. If you don’t have a knowledge repository already, set one up. Establish a central location (e.g., a shared drive, intranet site, or dedicated software) where other project managers can store and access documents, best practices, lessons learned, templates, process flows etc. Leverage technologyYou’ve probably already got collaborative tools like wikis, Slack, Microsoft Teams, or Confluence. Set up a channel for knowledge sharing and collaboration to support your community of practice. Make it a place where people can ask each other questions, so you can help each other out in real time. Reward sharingIf someone is supportive of knowledge sharing, recognise that and thank them. You don’t have to be their line manager to nominate them for an internal recognition award. Drop a note to their manager and say how much you appreciated their input. Feedback from conferencesThis is something that has worked well for me in the past. If someone has been to a conference or some other kind of professional event, get them to do a short brief to the rest of the team. They can share their key takeaways, talks they enjoyed, thoughts and reflections on the event. It might encourage others to go next time. If you hear about free webinars or other training opportunities, why not share them round with the people in your community of practice? Afterwards, meet up and discuss your key takeaways. You could even watch the webinar as a group – host a watch party! How do you foster an environment of knowledge sharing in your team? Let us know in the chat below! |
Benefits of visual reporting
| We do a lot of our reporting in PowerPoint, which is a tool I like using. However, it does often involve recreating data from other sources on a slide so it can be included in a deck. Over the years, I’ve noticed a shift towards more visual forms of reporting, like dashboards and slides. Slides lend themselves to graphical story telling far better than documents, and are good for the busy exec who wants to flick through the headlines without getting lost in the many pages of a PID or project plan. We all use a lot of words for our reporting, but if you’re trying to get your message across, making your reports more visual can make a difference. Here are some advantages to consider. Charts and graphs make your documents shorterCharts, graphs and tables make your documents shorter because you can say more in a small space. Visuals make your documents more concise and impactful, perfect for the busy senior manager who just wants to skim. Let’s face it, we all have information overload and busy brains, so the less work they have to do to understand the point, the better. Shorter documents reduce cognitive load and aid retention, so they might even remember the point next month! Colours highlight statusYou’re probably familiar with Red/Amber/Green colour coding for projects. The judicious use of colour makes it easy to see status at a glance. That means execs can focus in on the projects that need management attention. Watch out for how you use colour though, to make sure your reports are accessible to all stakeholders: readers with colour deficiency or people who prefer to print content in black and white won’t automatically understand your statuses unless you use the words too. Data presents the factsWorried about how your sponsor might spin project status? If you present the facts in graphical format, that will support the narrative. Even if your sponsor says everything is wonderful, sharing (for example) the number of red/high risks or open issues is a way to draw attention to the fact not everything is going as well as it could. Data, in graphical format, leads to objective reporting. Having said that, I’m sure you’ve heard people say that you can spin data in any way. So make sure your sources are clear and that you report like-for-like measures month-on-month for comparison. Links to drill down into the data will show that you value transparency. If you want to get better at visual reporting, think about where the data is coming from and how you can present it. I got some amazing tips from the book Good Charts by Scott Berinato. It is an eye-opening look at how to position your data for maximum understandability and storytelling. As well as the analytical thinking that you’ll want to do before you present any data, it’s also worth brushing up your technical skills, whether that’s a quick PowerPoint course or making sure you know how to use all the dashboarding and customisation features of your project management software, so you can get the data out in a format that makes it easy to share and talk about. Lots of common project metrics lend themselves well to being presented visually: timelines, budget allocations, pie charts of risk ratings and so on. Why not experiment with what you can make more visual in your next project update? |
Psychological safety: The bedrock of team performance
| Psychological safety, as I think of it, is the way that you show up at work and how much risk you feel yourself in when expressing your opinions or when choosing a course of action. If it feels ‘safe’ you’ll speak up when things are wrong, suggest new ideas and call out bad behaviour. If it doesn’t feel safe, you’ll keep your head down. On a project team, psychological safety is important because you want people to challenge poor ideas or speak up when they see a better way of doing things. And also because we are nice leaders and we want people to be happy at work, without second-guessing what their boss is going to think all the time. In an environment where psychological safety is present, people feel that it is safe to take risks. They might try a new solution or propose a new way of working. They might come up with an idea and implement it, or opt for a new technology over a proven one because it might be better. They also feel that it is safe to speak up and express ideas. They’ll speak in meetings, bounce ideas around, build on other people’s ideas and say when they don’t think an idea will work. The benefits are clear. You will see better team collaboration. People will be more creative and prepared to innovate. You should end up with better problem-solving and decision-making. And it will feel like a nice place to work surrounded by professional adults. How do you know if you’ve got psychological safety in the team?It’s probably easier to look at what the environment looks like if you don’t have psychological safety. You’ll see:
People might not say out loud: I was too embarrassed to say what I thought, but you might pick up on it either through one-to-one conversations or body language. If you want to find out more, you could survey the team or use other feedback methods, but if the environment doesn’t feel like one where you can speak freely, frankly I don’t think you’ll get a lot of good out of those methods. It is probably best to build good relationships with some of the people who exhibit more confidence or who contribute the most and talk to them openly about your worries for the team. The trouble with projects is that they happen inside the culture of the organisation, so while you might want to create an environment where people feel safe, if the rest of the organisation isn’t backing you up, that can be tricky. How to create a safer environmentIn your leadership role, you can model vulnerability and openness. Share what you’re comfortable sharing. Lead by example. Be consistent in your actions and expectations and demonstrate the behaviours you want to see. Encourage and reward contributions. Let people know you appreciate their ideas even if you don’t end up using them. Value diverse perspectives. Ask for them, incorporate them and let people know that their voices are being heard. Again, if they share their perspective and you can’t do anything with it or affect any change, at least pass that back to them. A lot of what you can do centres on establishing norms for respectful communication. For example, regularly ask for feedback, through anonymous suggestion methods if necessary (and people are wary of Microsoft forms not being truly anonymous). Handle conflict early when you spot it, and look out for those people who are showing signs of being resistant to change and support them. Schedule some team-building activities, but not awkward cringey ones, things that the team actually will be interested in doing. Over time, hopefully you’ll see that the feeling in the team has changed. I think it’s a hard thing to measure, but you might see results through employee surveys, perhaps in responses to do with belonging, or feeling understood/appreciated etc. What’s more evident is that you’ll probably feel it. You can observe the team dynamics and notice what is different. However, you don’t want to lose that and slip back into old ways, so keep psychological safety on the agenda. Ask people how they feel about working in the team now, and what else you could do together to encourage good working practices. Then act on their suggestions. |






