By Janus Boye
Martin on stage talking about ethical software design at the Boye Aarhus 20 conference
If your IT projects hurt, you are far from alone. There are many reasons why these things go wrong, even with smart people and good intentions all around.
Martin Michael Frederiksen is a self-proclaimed grumpy project realist and a seasoned Danish software executive. He recently created a top 10 list with the usual painful symptoms which caused some good debate on social media. As it turns out, all these digital projects we've been doing still have a success rate with plenty of room for improvement.
In a recent member call, we reviewed his list of usual pains and extended his list of helpful tricks. Below I’ve shared both his lists, summarised the highlights from the call and towards the end, you can also find slides and even the entire recording.
Let’s get to it. What’s the usual symptoms for IT projects?
10 reasons why IT projects fail
With his 25+ years of experience, Martin jumped straight to it and shared these 10 reasons:
Poor Communication. It usually starts with a half-done specifications document, and more time is needed to identify the pitfalls.
Lack of Clear Objectives. Project manager: Deliver top-12 tasks as fast as possible. Customer: Deliver whatever features, but rollout in 20 countries in three days.
Inadequate Planning. GANTT: Everything is nicely linked to the next activity. Me: Endless planning shuffle.
Lack of Stakeholder Involvement. Manager: I don't have time to participate every second week. Me: Red flag.
Insufficient Resources. Customer: Please build this battleship. We have $100.
Ineffective Project Management. Don't try to be service minded. It may create the opposite of what you strive for. Be the grumpy project realist.
Scope Creep and Feature Creep. Some people think their job is to add seven new ideas in every meeting.
Technical Challenges. Innovation is risky, and sometimes the risk wins. Prepare for it.
Poor Quality Assurance. You may need 1 in QA for every 3 developers. There's a limit to how fast a person can do proper testing.
Resistance to Change. We all want change. Nobody wants to change. That's why you can't change people, but you can change people.
Any of these sound familiar?
Thankfully, Martin also shared a list of helpful tricks, which you can apply. Not a cheat sheet, but close.
Three things that might help
His first trick focused on alignment and he described it like this:
Ask five people in the project about what they see as easy tasks, difficult ones, and risk factors.
Ask them if they think it will be delivered on time and in quality. Ask them about success criteria.
There are three outcomes: They are all positive. They are all negative. They have different opinions.
As he said, this is a good way to have an honest conversation about what is really going on.
The next one is all about working backwards from a test report to ensure quality. Or in other words - a good outcome and not just some output:
During the project, ask for a test report from a previous sprint (if you use agile).
Read it, try to backtrack test cases to requirements, and see if you can verify that a task is actually done and in expected quality.
This is often a scary exercise.
His third trick tests, so to speak, the confidence level in the team:
Ask the team for a great Friday evening to plan the release party.
Check if they buy into a release party or prefer a later day for the event.
We then turned to the group to hear their tips and tricks.
Four more things to think about
First up, we talked about the good practice that you enforce that change requests either costs extra or delays the project. The tendency to be flexible and please the big boss can easily turn to pain.
We then turned to the many distractions that tend to happen for everyone involved. Create a quiet working environment where folks can actually get things done. Perhaps even put on the ‘Do not disturb’ sign at regular intervals.
One of the participants in the call also reminded us that these projects are rarely so much about technology. These are people projects and relationships and social capital will cure most pain.
Finally, I was reminded of the old adage by Morten Elvang: Most organisations suffer from project overload. They are simply trying to do too many things at once. Might there be a project you can stop? Might there be an opportunity to delay starting the next project, so that you can get more done. Also, if milestones are missed, do you just keep going at the risk of negatively impacting other projects? While it might sound counterintuitive, doing less projects at once will likely cause less pain and result in getting more done.
Learn more about leading IT projects
We’ve written quite a bit about this topic. Here’s just three recent posts:
The conversation naturally continues in our community, notably the digital project manager groups and at our regular conferences.
You can also download the slides (PDF) or even lean back and enjoy the entire recording from the call.