Do you have your head in the sand about these project challenges?

From the The Money Files Blog
by Elizabeth Harrin

A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts. Written by Elizabeth Harrin from RebelsGuideToPM.com.

About this Blog

RSS

Categories

accounting, agile, ai, appraisals, Artificial Intelligence, audit, Backlog, Benchmarking, benefits, Benefits Management, Benefits Realization, Bias, books, budget, Business Case, business case, business case, Career Development, Career Development, carnival, case study, Change Management, checklist, collaboration tools, communication, Communications Management, competition, complex projects, Conferences, config management, consultancy, contingency, contracts, corporate finance, corporate finance, cost, Cost Management, cost management, credit crunch, CRM, data, data security, debate, Decision Making, delegating, digite, earned value, Education, Energy and Utilities, Estimating, events, FAQ, financial management, financial management, forecasting, future, GDPR, general, Goals, Governance, green, Information Technology, Innovation, insurance, interviews, it, Knowledge Management, Leadership, Lessons Learned, measuring performance, Mentoring, merger, methods, metrics, multiple projects, negotiating, Networking, news, Olympics, organization, Organizational Culture, outsourcing, personal finance, Planning, pmi, PMO, PMO, Portfolio Management, portfolio management, presentations, privacy policy, process, procurement, product management, productivity, Program Management, project closure, project data, project delivery, Project Success, project testing, prototyping, qualifications, Quality, quality, Quarterly Review, records, recruitment, reports, requirements, research, resilience, Resource Management, resources, risk, Risk Management, ROI, salaries, Schedule Management, Scheduling, scope, Scope Management, security, small projects, Social Impact, social impact, social media, software, software, software, Stakeholder Management, stakeholders, Strategy, success factors, supplier management, team, Teams, testing, testing, timesheets, tips, training, transparency, trends, value management, vendors, video, virtual teams, workflow

Date

Categories: Benefits Management, Change Management, Quality, Risk Management, Stakeholder Management, training

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.)

Stakeholders are reading your communications

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.

The training you’ve scheduled is enough

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.

Your change management plans are adequate

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.

The UAT plans are long enough

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.

Risk identification has spotted everything

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 OK

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.

Benefits are understood

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 is no conflict in the team

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.

Quality is being managed OK

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.

There is no technical debt

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!

Posted on: October 15, 2024 08:00 AM | Permalink