Summer Stings. How To Treat IT Project Management Pain Points
I was sat in the pub beer garden at the weekend when a customer was stung by a wasp. A passing waitress saw this and instantly she returned with ice, cotton wool, some apple cider vinegar and an EpiPen (just in case).
Now, I've treated wasp stings with calamine lotion in the past, and I have applied an ice-cold compress, but the apple cider vinegar was a new one on me.
Within seconds, the swelling had gone down and the stung customer was back enjoying his pint.
I asked the waitress where the idea for apple cider vinegar had come from and she just smiled and said, "Life experience."
IT Projects are like this pub beer garden. One minute you're sat enjoying the peace and calm and the next you feel a seemingly unprovoked sting as if from nowhere, that leaves you in agony. Knowing how to treat these IT Project pain points is equally down to life experience - sometimes you need help from a passing waitress or in this case, a great IT Project blog.
Five IT Project Stings and How to Make Treat Them
1) The Sting: Scope Creep
You have the work planned out, resources allocated, everyone knows what they're doing and when and then ... the client changes the requirement or thinks of something that "it would be nice if" your project could deliver. It's really common for client requirements to change and with your "can do" attitude you will try to accommodate. The sting here isn't just the extra work that you will have to fit in, you have to take time to properly understand the client's changed need and then reassess resources, decide who will complete which tasks and communicate all this with your team.
From the start, define, agree and then stick to a scope change approval process. Make sure that there is an understanding that mid-lifecycle changes will also probably lead to changes to cost and timings. When a change is requested, detail all the requirements that have changed, list everything that the client has requested and communicate to your client how these changes will affect the scope, cost and delivery date of the project. You can also set and agree response levels based on time and cost, effectively approval filters for requests, so easily accommodated changes can be actioned by without senior approval whereas changes that need extra cost, resources or time must be passed to a senior project leader for approval.
Pre-agreed parameters take the awkwardness out of any change request. Thorough cataloguing gives you and your project stakeholders a quick reference point to check and communicate scope change.
Finally, the Project Management as a Service market is great for taking the sting of scope change, the extra, on-demand resources that PMaaS can offer give you unlimited response options.
2) The Sting: Miscalculated Time Estimates
How tight are project deadlines these days? Everything in tech is moving so fast! Clients want delivery and return on investment as quickly as possible. This can sometimes lead to hurried and, therefore, unrealistic forecasts. You don't have a crystal ball, you can't predict everything that's going to happen. Like planning a road journey without factoring in traffic delays, accidents, red lights and roadworks - great if you have a clear run but the smallest delay means you'll arrive late.
"Cut yourself some slack", I often hear this from teams at the point where poorly estimated time forecasts are causing pain, they mean it in the sense of "don't beat yourself up about it". Actually cutting yourself some slack is a great preventative measure. Back in the day, cutting yourself some slack meant giving yourself more rope than you think you'd need on a sailing boat. For plain sailing in your IT Project, build in a time buffer on each task so that if one element is delayed it doesn't impact your final delivery date.
If unrealistic time pressures are being imposed by unavoidable end client or organisational demands then consider bolstering your resources with PMaaS back up.
3) The Sting: Lack of Transparency
I remember reading a post mortem on a failed IT Project some years back that described the project's transparency as "opaque". It actually made me laugh and I've never forgotten it. It's really important for Project Managers and stakeholders to be able to get a view of how the project is progressing, where each task is at, who is doing what, etc. Every project team will tell you that this is what they have but this never really gets tested until someone actually needs to take a look. It's like thinking that car your engine is running well, then it fails and you need pop the bonnet to take a look, only to be met with plumes of smoke.
A task management tool allows quick access to the progress of your project, and the best project management software products give real-time updates which let everyone keep a check on where the project is at - without having to gather everyone around the water cooler for a catch up. You know all this though, and I know all this too - so why does it sometimes fail?
It's what I call the "Sunday Night Homework Trap". Remember, at school, you'd be set some French homework that had to be handed in two weeks later? When did you do it? That night? Or was it the night before it had to be handed in? Honestly, when I was a kid, "Last Of The Summer Wine" used to come on the telly on a Sunday and I'd think "Arrrgggh! French homework."
So the key is to actually fill in the information required for full transparency at the earliest possible moment - out of date progress reports can cause as much "project panic" as actual, real problems, so develop an open culture and make filling in the data fields in your software package a daily habit.
If this is a struggle consider turning to your PMaaS partner for end to end Project Management Office which will come with transparency built-in!
4) The Sting: Lack of Accountability
Accountability isn't (just) about deciding who is to blame when something goes wrong, but it often carries this negative connotation and this may be the reason why project leaders sometimes fail to create a culture of accountability. Finger-pointing isn't great for team spirit, so accountability needs a rebrand.
Being accountable means being a team member who can be trusted, accountability means being willing to accept responsibility for your actions (and the plaudits when your actions make you into a hero), accountability means that you don't have to have your project leader stand over you all the time to make sure you're nailing it! Some project leaders are caught in the "accountability means blame" trap so find it hard deciding who is responsible for what, especially when there are multiple team members working on the same task.
Some teams are just too close-knit and friendly for individual accountability to deliver fully, the ‘we're all in it together attitude’ is great as long as having your colleague's back means helping recover after a mistake, not cover it up. In my experience, teams without proper accountability are often ones where a project leader has risen through the ranks to a senior position and now finds it awkward holding former colleagues to account.
Create a culture where it's OK to fail, to err, to miscalculate, to get it wrong, to be human - as long as you are open and honest and take the best action to put things right. In cultures like this, it's amazing how everyone does have each other's backs and pulls together for the greater good. In cultures like this, it is also easier to assign responsibility because doing so doesn't feel like you're setting a colleague up for a carpeting later on.
Accountability needs to be clearly established from the start, without any room for misunderstanding, and this way all parties deliver the exact responsibilities given to them.
Again, Project Management as a Service solutions, like end to end PMO, can take the heat out of accountability, especially in teams that are too close-knit or where a former colleague is now the leader. External resources don't worry about internal issues or as one colleague puts it "the rudders on the wings of a plane don't care about the baggage on board, they're too busy steering the plane."
5) The Sting: Misinterpretation / Miscommunication
Another area for problems is when stakeholders and end clients misunderstand IT-specific terminologies, protocols, methods and concepts. I have a rule that if the client has a false understanding of IT project deliverables, personnel, methods, or tools - then this is our (the project team's) fault. Unrealistic project expectations and assumed deliverables really leak perceived value from your delivered project – so communication is key.
An IT project manager must liaise with the client in order to help them understand what exactly can and will be achieved and more importantly (perhaps) what cannot and will not. Sometimes we assume that everyone is as clued up as we are about the workings of our IT Project, especially stakeholders, sponsors and clients who surely have a vested interest! The truth is that they do have a vested interest but only in the result and the delivered project. They don't care how it comes into being, no more than you care how a plane takes off and stays in the air, you just care about getting to Lanzarote! An educated client, ultimately, is a happy client, they don't need to know the workings of Waterfall or Agile, but when they are clear on what they will and won't deliver, your job becomes a lot less stressful.
Before I buzz off then, to conclude, the quicker you identify pain points within your IT Project the quicker you can deal with and get past them. They can and often do blow up just like wasp stings, they cause pain, irritation and discomfort and in rare cases, they can even be fatal.
As always, prevention is better than cure, talk with your Project Management Services partner, arrange a review of your portfolio, initiate a gap analysis and discuss what options are available in the ever-expanding PMaaS universe.
That guy in the pub garden left with an arm still smelling of apple cider vinegar, how much better to prevent being stung in the first place?