I think "amazing" is the most over used word in the English language these days, usually with the middle 'a' elongated, "amaaaaaaaaaaaazing". I blame Love Island. Anyway, I digress, the chap I was talking to seemed genuinely taken by the ground-breaking, "amazing" new concept that I'd shared, he picked my brains for a good few minutes and even grabbed his iPhone to create a note.
What was the thing I'd mentioned? SMART Targets.
I know! Hardly ground-breaking or new, you might say SMART targets are even a project management basic. He was right on one thing though, they are "amaaaaaaaaaaaazing" but if this one project manager is anything to by, it seems some projects have lost the art of SMART, or worse still, never learned it in the first place. "Amaaaaaaaaaaaazing"
This got me thinking. I've noticed other concepts that, to me, are IT Project basics that are increasingly being forgotten, overlooked or are just not part of the DNA of Project Managers and their teams. In this short series, we'll explore some of them. If your project capability is stretched, if you are having to cut corners on project basics (like SMART targets) then the Project Management as a Service sector has an abundance of resources to help, from better project software to end to end Project Management Office.
Today then ...
Every day we subconsciously set ourselves thousands of targets, whether it be to make an early morning coffee or to remember to put the bins out on bin night, however some goals require a deeper level of goal setting, this is where SMART targets come in handy.
The notion of SMART targets may appear basic but increasingly and perhaps paradoxically, as IT projects have become more complex, teams are forgetting to do some of these basics. It is a common symptom that I see in projects that are failing - teams are to busy working in their projects to work on them.
To quickly refresh our minds, let’s look at exactly what a SMART target should consist off, what each letter stands for ...
What is it that you’re trying to achieve, try to be as specific as possible when deciding on your goal. For example, rather than saying 'I want to complete the coming sprint' state exactly what you want to complete, this way you are more likely to focus on those specifics. Habit 2 of Steven Covey's 'Seven Habits of Highly Effective People' is "Begin With the End in Mind"
How are you going to measure how close you are to completing your target? How will success be measured? I remember this quote from way back in my school days, it is from Galileo Galilei, it goes "Measure what is measurable, and make measurable what is not so." Love that! There are many different ways of measuring IT Project success, for example you may decide that you want to achieve a certain number of deliverables, or a certain level of stakeholder satisfaction. You may want to meet a budget, deliver a specific return on investment (ROI) or level of quality.
Attainable / Achievable
Making sure a target is achievable is key. Setting unrealistic targets will likely lead to unnecessary stress as well as failure. All too often, physical and financial resources are the measures of attainability but it also pays to consider the experience of your team, i.e., how it will feel for them. If delivering this is going to drive them to drink or to look for work with other projects, then your goal is not achievable - at this moment! Consider PMaaS resources to bolster your capability and ease pressure!
When anyone sets a goal it should be relevant to their individual needs. This is why most diets fail! If the need for chocolate cake, a glass of wine and fish and chips on a Friday is greated than the need to lose weight, i.e. weight loss is not a relevant goal, guess what will happen. The same goes for goals set in IT Project Management. All goals should be relevant to the overall aim of the software being developed, the business change that is needed or the strategic goals of the organisation.
Timely / Time bound
Finally, you need to set yourself a completion deadline. It is important that the deadline is realistic but pushes the team to work hard. A project leader shouldn’t set their team a week to complete a task that should be done across three weeks, which sounds obvious but commercial pressure as they are, too many friends are burning out trying to deliver ROI unrealistically quickly. If you are feeling commercial pressure to say 'yes' beyond your current capability you should explore PMaaS.
Who are the fans of SMART targets? What benefits do they bring?
Surveys carried out by the Institute of Personal Management found that 62% of UK companies use SMART targets as a way of motivating talent and improve performance levels. Byron Pulsifer, an author specialising in self improvement books, champions them. He says that those who use SMART targets are much more likely to achieve their targets than those who simply state their goals. His stuff is worth a read!
Studies show that teams using SMART targets are much more focused on achieving their goals. Individuals understand what their goal is, as well as exactly how and when they are going to achieve it, they are therefore more likely to focus on completing the task required and achieve the overall goal.
SMART targets fit perfectly into the software development cycle and most project management methodologies. Effective teams will break development up into short sprints, at the start of these sprints decide on what they are looking to achieve. Teams design SMART targets in order to decide exactly how they are going to achieve their goal as well as whether or not their target is achievable.
SMART targets may also lead to higher customer and end user satisfaction, part of designing a SMART target is ensuring that your goal is relevant, this allows your team to ensure that what they are working on is relevant to the "customer’s” needs.
Are there are drawbacks to SMART targets?
Whilst SMART targets are widely considered the most effective goal setting method, like everything, there downsides.
In IT Project Management, you may have to guard against SMART targets limiting creativity, especially when developing software intended to disrupt. Teams usually decide on a method at the same times as agreeing their end goal and once agreed SMART targets don’t always allow for changes to be made. This prevents scope creep from occurring, which is good, but sometimes scope creep can allow teams to explore new ideas and innovate their software.
Most research shows that SMART target, while great for sprints, are less effective for long term goals. Therefore, IT project teams may need to look at other goal setting methods for more 'overall goals'. However, as previously discussed, when you break overall goals into manageable work units - SMART is king!!
You should also be cautious when deciding on overall goals and deadlines. When used incorrectly, for example setting unrealistic targets (like short deadlines), SMART targets can place too much stress and pressure on team members and eventually lead to project failure, it's much better to allow your team a few extra weeks to perfect a piece of software rather than forcing them to rush and produce a poorer piece of work.
Writing all of this feels like I'm teaching your Granny to suck eggs! You know all of this! I know all of this! However, with IT Project failure rates as consistently high as they are, maybe we need to remind ourselves of some of these basics. In the opening, you read that some teams are just too busy working in their projects to work on them and while I understand this, it is also short sighted in the extreme. Project basics are like the plants in your office, they need to be watered daily and fed once in a while otherwise you look up one day and find that they've withered and died!
The most basic, common and therefore ordinary goal of EVERY IT Project is that they are initiated to succeed ... to deliver business need or facilitate change. That's it! Simple. IT Project success is therefore not a mystery but a series of basic, common and ordinary things that are all done extraordinarily well.
Treat yourself to some thinking time this week, if you are struggling with your IT Projects of late, is there a project management 'basic' that you need to water!
Find out more about Project Management as a Service from Stoneseed
For context, I am writing this on the Wednesday after England's Cricket World Cup win at Lords and Novak Djokovic's Men's Singles victory at Wimbledon. Both the New Zealand cricket team and Roger Federer must have been able to feel their respective trophies in their hands but their opponents had that little added ingredient, more than luck, there was a tenacity, a drive, a never say die strength that, if you could bottle it, would make you a millionaire.
As a cricket fan, it has taken me this long to process what I saw on Sunday. The match had ended in a tie which led to a tie-breaker, which also ended in a tie all leading to a super over that delivered a frenetic end to a match that had sauntered along in slow motion until the last hour. It felt just like a lot of IT projects that I've seen teeter on the brink over the years - as convoluted, as exciting, as frustrating, as nerve-jangling, as unpredictable and, ultimately, as satisfactory.
Eoin Morgan's England team were predicted to take this tournament by the scruff of the neck, they were described by one pundit as "the demolition men" who destroyed teams in their wake, notching up huge totals along the way. Ahead of the final thought, I knew, in my heart of hearts, that it wasn't going to be easy. As a cricket fan, you know it never is with England, just like IT Projects are never easy. I just didn't realise it was going to be as hard as it was, a sentiment that many IT Project Managers can also relate to.
On the same day, across London at SW19, after almost five hours on court and over 400 points of tennis, the men’s singles final at Wimbledon was decided by a first-to-seven-point tiebreak. Roger Federer, now 37 years old, an eight-time Wimbledon champion, out-played Novak Djokovic for much of the match. Federer hit more aces, he won more points and he broke serve more often. Djokovic showed why he is the top-ranked male player though, he dug deep. In the 16th game of the final set, Djokovic executed his game better when it mattered and dominated the tiebreak climax to secure his 16th major title. Phew!
So, what's this got to do with IT Project Management?
It's simply this. While it's quite right that the likes of Djokovic, Stokes and Morgan get their adulation, for IT Project teams, long days that make you ache from head to toe are a normal occurrence. It's what we can learn about endurance, resilience and teamwork that could help you win with your next IT Project.
1 - Strong Leadership
England captain Eoin Morgan demonstrated his leadership skills, not just during the match, but apparently, also at a reception thrown by the Prime Minister at 10 Downing Street. The team were a little rowdy, chanting "Allez Allez Allez" when Morgan intervened and said, "Look, guys, we’ve got to calm it," according to reports in the Daily Telegraph. They calmed it. Firm leadership and respect from the team for that leadership are vital and sadly missing in many of the IT Projects we are asked to help bring back into line.
2 - Deliver When It Matters
A lot of struggling projects have a lack of clear prioritisation. Look at that Wimbledon final, Federer hit more aces, he won more points and broke serve more often but it was Djokovic who executed his game better when it mattered. Be mindful of what really matters in your IT Project and focus your A-game on those areas.
3 - Consistency
Djokovic, Federer and Rafael Nadal, who fell to Federer in the semi-finals at Wimbledon, have an unprecedented stranglehold on men’s tennis. Federer is 37, Nadal is 33, Djokovic is 32. The greatest male tennis player of my childhood, Bjorn Borg retired at 26. None of today's "veterans" are playing their very best tennis these days, but all are playing with a steady consistency that is keeping the newcomers out of the top rankings.
This consistency is something we should aim for. All too often I see the same project team deliver a resounding success and then follow it with a turkey. Be a student and practitioner of what works for you!
4 - Use External Resources
Coaching obviously played a huge part in both the sporting successes outlined here and your IT Project partner can be a really useful independent pair of eyes when you can't see what's going wrong with your IT Project.
Beyond this, it's worth developing a sense of flexibility about who makes up your IT Project team. Don't feel that you have to rely on your in-house squad when there are a range of resourcing solutions available from the Project management as a Service market. One Project leader told me once that she feels like they have failed if they have to reach out to PMaaS and this way of thinking needs a reframe. Traditionally, the England team would have all been born in this country, a casual glance at Sunday's heroes reveals a different story! Captain Eoin Morgan was born in Dublin, Jofra Archer in Barbados, Jason Roy in South Africa, even man of the match Ben Stokes was born in New Zealand - you get my point! You don't have to rely on 'home-grown' talent for your success.
5 - Celebrate and Remember It's Fun
Watching Djokovic during his game (and Federer too) was a lesson in celebrating each point. I mean, they don't run around the court in a lap of honour at the end of each game but there is always a self-congratulatory 'air fist' or a growled "YES". No little victory goes unacknowledged and it should be the case with IT Projects. We're really good at chunking work into manageable units, like sets and games in tennis, but we are often really bad at giving ourselves credit where credit is due.
I got really tense watching the cricket, I paced around, I chugged a beer or two, I bit my fingernails and then I remembered that I loved cricket and that this was meant to be fun. We sometimes forget to enjoy ourselves when delivering IT Projects too. C'mon! This is the best job in the world - let’s remember to enjoy it!!
6 - Stay Calm
I recall Stokes and Butler coming out to bat to a tumultuous Lord's roar! They stayed calm hitting two boundaries on their way to posting 15-0 from their six balls. Under such pressure how easy would it be to lose your head? Under the scrutiny of the c-suite, the clamour for transparency from stakeholders, the pressure for successful delivery, how easy is it for us to lose ours?
I remember, early in my career, a project manager having a full-on nervous breakdown over his IT project, I vowed then that none of this was worth shortening your life for. Panic makes terrible choices!
So that's it really! It's all about having that special something extra in your locker. Stokes has it. Djokovic has it. Morgan has it. YOU TOTALLY HAVE IT!
'&' or the ampersand is often misused and misunderstood. Largely thanks to social media communications, where you are limited to a maximum number of characters, this misuse is fast becoming something of a trend.
Again, so what?
I asked ten IT Project people to share what they knew of ampersand. One nailed it, eight out of the ten said it was short for 'and' - and one hilariously answered, "Isn't it in Norfolk?" I think (hope) that he was joking. Although to be fair, Ampersand does sound like somewhere you'd take the kids crabbing on the North Norfolk coast!
Is it a worry that nine people I asked didn’t know that usage rules exist? I mean, if nine intelligent people surveyed don't know the rules, then surely that means that 90% of readers won't know either so they won't notice. Surely?
Hmmmmmm. Maybe not.
To Susan, a CIO friend, "ampersand abuse" is a pet hate and a real nails down the chalkboard issue.
Susan wrote to me recently, "If you wrote up project documentation and substituted ‘and’ with 'n', as in rock 'n' roll, you'd have no credibility at all! To me '&' is the same."
When put like this, you do wonder why project managers take the short way out? What’s wrong with writing “and” - if "and" is what you mean?
"If a project manager can’t write a document correctly, what else are they doing to take the easy way out," added Susan.
The first thing about ampersand is that it doesn't necessarily mean 'and'. Here's a handy dictionary-style definition.
Ampersand: a stylized, contractual form of the Latin word "et". Although the Latin word "et" does mean "and", it is improper to substitute "&" for "and".
Many people incorrectly substitute this symbol for the English word "and".
Ok, but again, SO WHAT?
Here's why I think it does matter.
1 - It's a short cut. As IT Project Managers, a big part of our job is to find short cuts to expediate delivery or reduce costs. It is important, I think, that we convey the impression that we know which short cuts to take and when. Do pages of misused '&'s do this? I'm not sure it does.
2 - Another huge part of what we do is methodology. The CEO, the Finance Director, the whole board at most companies that I have dealt with do not understand the rules of Agile or Waterfall or any IT Project methodology that you care to mention. When greenlighting a project, however, they are saying that they trust that you DO. If your CEO knows how (and when) to use '&' and you have used wrongly it 40 times in a project proposal, they may ask what else are you bluffing knowledge of. It sounds daft but perception is reality.
3 - Our documentation matters! Grammar experts say that '&' should not be used except for in the most informal of communications. A project initiation document is among the most important documents to the success of an IT Project. Anything that creates an impression that it is not should be avoided. Susan the CIO asks, "Would you type a PID in the 'mistral' font or 'windings'? Would you sketch it out in crayon? Of course not, it commands your best presentation skills - take some pride!"
4 - It's a trend! Why follow a trend, if you don’t understand it? I was in a meeting last week where a forty-something-year-old project manager said, "Awse!" It was short for awesome. There was a tangible sense of cringe about the room, even the PM himself looked uncomfortable. Apparently, it's a trend! Doesn't make it right! To put this in perspective, these are fashion trends for 2019: 50s and 60s era couture gowns reworked shorter; volume dresses; corsages; ostrich feathers; front-loaded tool belts slung across the body; and nineties style acid and light-wash denim. Do you understand these trends? Will you be wearing them? So why follow the '&' overuse trend? (Although the light wash denim sounds cool.)
5 - It may also dilute your message. My copywriter friend Gareth was on a course once where the lecturer stated that in a list, a final item that follows the word ‘and’ is more likely to be digested by the reader than one that follows ‘&’. It’s something to do with the reader being hardwired to take pause when faced with ‘and’, whereas the attention zooms on and over the ‘&’.
6 - Finally, remember I said that out of ten IT Project Management professionals, only one nailed the rules of the ampersand? Yeah, about that, Martina is from Slovakia. Come on people! We need to pull our grammatical socks up!
This may be a tongue in cheek rant or I may be the self-styled grammar police and mean every word of it. I'll leave that for you to decide (by the way, my colleagues need not reply).
The point is though, that attention to detail has NEVER been more important. Your organisation needs a decent return on investment and you need to maintain high levels of successful project outcomes to get the next green light. Therefore, we all need to get every aspect of IT Project delivery right.
"Who’s there?" we replied.
"Bless you!" he said drily, handing us a handkerchief. Remember, the kid was about nine! Cute!
Some other guests walked into the marquee, so he moved onto this new audience.
The elderly couple laughed. We smiled.
Then a third, a fourth and a fifth couple wandered in, they were all greeted by the same joke. All of them laughed but the rest of us no longer found it funny. Around the tenth airing, someone who'd arrived before us whispered that it was really starting to grate! Poor kid!
It got me thinking though.
The joke caused a genuine reaction the first time we heard it; less so the second; even less so the third; and so on. You quickly become desensitised to something like a joke - it affects you less. So if we can do that automatically with something funny, why do we hold on to bad experiences? Sometimes for years! Why do we let negative episodes in our careers affect how we approach the here and now?
My colleague is working with an IT Project team who are struggling to innovate. Their issue isn't scope creep, nightmares with budgets, problems transitioning into service or any of the usual suspects - it is the baggage they are lugging around! The baggage of past project fails, misjudgements and miscalculations are holding them back.
What's that old adage? Why do airlines have baggage limits? Because if they didn't their planes would be too heavy to take off! So, it is with these guys. The past experiences of this team are sandbagging their potential. Their past is influencing their decisions, creating a risk-averse environment where innovation just couldn't happen! They can't take off.
There's a very primal instinct behind all this by the way! Often there is a part of us that doesn’t want to let go of past trauma because erasing the memory completely might leave us vulnerable to the same thing happening again. If it’s always on your mind then you’ll always be on your guard, on the lookout for the potential for it to recur - then can run away from it before it even starts to cause problems.
Congratulations if this sounds familiar - it means you’re human!!!! It's this instinct that kept our ancestors safe from sabre-toothed tigers and we still have it today, long after the tigers have died out.
Thing is if you are already biologically programmed to be affected less and less by that joke - is it possible to reframe your thinking so that more negative events affect you less and less over time too?
It turns out that you can! Furthermore, the results are amazing in our world of IT Project Management.
Sometimes it can take a fresh pair of eyes to point out that you've become risk-averse or that there may even be a Project Management as a Service solution to recurring challenges that eliminates any risk altogether.
That team struggling to innovate had settled into a routine of not doing so through fear of failure and as a result they were getting 'routine' outcomes. They weren't failing, per se, but neither were they setting the world alight! They were letting past experiences influence their decision making. Time and again they’d had to explain to stakeholders why their project had delivered, not with a fanfare but with a whimper. It was becoming as funny that knock, knock joke!! Something had to change.
With my colleague, they have explored the possibility that failure doesn't actually exist, i.e. it is only failure if you don't learn from it; they have compared the 'worst that could happen' with the 'best that could happen'; and they have looked at the team's three biggest failures and brainstormed possible actions they’d take should they happen again. In each case, the potential benefit from innovation outweighed the worst-case scenario and, anyway, resources from the PMaaS market could have been called upon to rescue each situation. There you go, a lesson eventually learned from each of the so-called previous failures!
There's a lot of talk these days about 'mindfulness', about living in the now rather than the past and this may be the key here. The Project Management as a Service universe has exploded with new solutions and resources since each of your past 'failures' happened. You cannot afford to approach challenges with the mindset that you had the last time you faced something similar – the world has moved on and so must our thinking.
These days, a return on investment is not an added bonus, it is a key expectation and that often comes down to the quality of the project you deliver and how it transitions into service. Accessing the most up to date project delivery tools is just not possible if your mindset is anchored in a time when perhaps fewer options existed.
Maybe it’s time you stopped letting your past experiences influence your present? Maybe it’s time to see how current solutions could help you to innovate? Maybe it’s time just to try something different.
Like that kid at the wedding, project’s that don’t deliver their full potential are no laughing matter. It’s time to stop being the butt of this joke.
OK, without getting nerdy, although the terms are often used interchangeably, March 12, was actually the 30th anniversary of the World Wide Web. But hey, semantics – right?! Whatever you want to call it, it has been transformational.
I was listening to the radio and the presenter and callers were having fun remembering how things used to before the web (if you wanted a blouse - you had to visit a High Street store said one - oh the humanity!!!) and they were listing things for which they are grateful.
As the programme went on, it started to dawn on me that the majority of callers were only using the internet for a fraction of its potential. One woman actually said her ABSOLUTE favourite thing about the web was the funny animal videos!!! Also, many were still using the internet the same way they had when they first encountered it, typing Google searches rather than calling for Alexa, for example.
This got me thinking.
Ask anyone who was working in IT in the days before the web, what it was like. They’ll tell you how the internet has been even more transformational for us, but, just like these radio callers, are WE getting maximum gains from it and the IT advancements it has brought?
Sometimes we can forget how much the internet has changed things and how quickly that change has happened. As businesses and organisations, we can be guilty of not updating our perceptions of what's possible, or how we use it, and so get left behind. The available technology and solutions have outpaced a lot of organisations’ ability to keep up.
I asked IT Project friends why they'd like to buy Tim Berners-Lee a drink ..
And this is what they said ...
1 - Knowledge is power
This came up in the radio phone in! The history books are full of how, throughout time, knowledge was restricted to the elite. Not anymore! YouTube has thousands and thousands of hours of educational videos (and plenty that are not quite so educational too) and Wikipedia is a reference library of millions of entries on everything from particle physics to over 5,000 words on the orientation of toilet paper (over or under?) and, closer to home, CIO.com and pmi.org are fabulous resources for IT Project Management. Thanks to Tim Berners-Lee's invention anyone with an internet connection can access the sum total of human knowledge - from a device that they keep in their pocket.
Some of the Project Management forums are a great source of inspiration and information and often it is a great comfort to find someone, maybe on the other side of the planet who has struggled with the exact issue that is keeping you awake at night. There is a whole section coming up on Project Management as a Service but thanks to internet connectivity there is a limitless resource for project management solutions. Which brings us on to ...
2 - Communication!
Do you remember the days when you would coordinate (even) an IT project in your conference room? With the advent of cloud computing, with mobile applications and constantly evolving project management software, you now have a global conference room. IT Project teams can discuss projects around the country and even across the world. Anecdotally, I reckon that four in ten project team members now work remotely, which allows companies to access talent and resources from all over the world through Project Management as a Service (PMaaS).
It means that developers and those tasked with transition into service can communicate effectively at times that historically would often leak value. Clients and stakeholders can have access to better progress updates, fuelling greater transparency and governance.
3 - Access projects anywhere, anytime
And it's not all talk. As well as improved communications teams are now working in real-time on their projects even when team members are spread across multiple offices.
Your project is always live, always to hand and, as updates sync automatically, always the most up-to-date version. This has been a game changer in eliminating time waste and driving greater return on investment (ROI).
Not too far back in the day, cloud-based project management software was prohibitively expensive, many small to medium-sized businesses were priced out of this market. Now, solutions are more affordable allowing companies with any budget, to do more and leverage greater returns.
4 - Easier and better compatibility
Compatibility has always been a headache for IT Project Management teams. Many still struggle with the transferring of data between different software solutions, even with the advent of cloud computing!
It is an improving situation though and software developers are actively now seeking ways to make cloud-based project management software compatible with the likes of Microsoft Office and Outlook, for instance.
5 - The PMaaS (Project Management as a Service) universe has exploded
Project Management as a Service (PMaaS) provides access to project professionals, resources and tools at a flexible and predictable cost. Whether it is a true end to end service, IT Advisory, Programme & Project Delivery or Service Delivery, access to Flexible Resources on demand, as a Service is booming. Thanks to straightforward cost models, businesses have an ever-increasing project management toolset to call upon.
Project, cloud transition and migration planning; vendor and system selection and evaluation; governance; delivery and post-delivery transition into service and stabilisation; cost management are just a few of the reasons that I would like to buy Tim Berners-Lee a pint!!!
So, there you go. Just five ways that the invention of the world wide web has allowed IT Project Management to develop and strive; to deliver greater returns on investment; and to move from a back-office function into a strategic business partner. It’s hard to fully grasp the impact of the Web on IT Project Management, largely because without it, none of us would actually be doing exactly what we do now.
It has been an utterly transformational technology that has reshaped every aspect of modern life but especially ours!
The problem is, that just like the woman whose favourite thing online was those funny animal videos, many businesses are not maximising the potential of these constant advances.
It is our responsibility, as IT Project leaders, to ensure that they do.
It's actually (paradoxically) both easy and hard to nail this. Some project teams struggle but, like with most things, you just need someone to show you how and from then on, it's easy! I believe with a little effort you can ensure that EVERYONE involved with the project knows what to expect and when.
Five shortcuts to managing stakeholder expectation
1 - Plan the journey together before fixing on an eta
One of the first questions a lot of clients and stakeholders ask when you meet to discuss a project is "What will be the delivery date?"
Would you plan any other journey like this? I mean if we decided to travel to Buenos Aires - how accurately could you predict an ETA? You wouldn't take a guess before breaking the journey down into its different parts, would you? You'd have to work out which airport to fly from; what time the departures are and how long the flights are; how to get to the airport and how you get from the airport to your destination at the other end.
Too many IT Project delivery dates are agreed without due attention to the tasks and milestones along the way. Like our journey to Argentina, break down the project into chunks and agree on scope and delivery timetables based on proper measured thought.
Funny story, back in the day some friends of the family who are London based Arsenal football fans, set off for an FA Cup tie in Wrexham. It was the days before Satnavs and the task of planning the route was left to an uncle. It was a good hour and a half into the journey before they realised that the route he had planned was taking them to Wroxham in Norfolk rather than Wrexham in North Wales. The moral is that proper journey planning may take a little time up front but it will pay back later with accurate timescales and clearly defined and agreed expectations.
2 - Your plan - KISS
KISS - Keep it Simple (for) Stakeholders
What this means, in essence, is don't overcomplicate documentation and plans. I recall a project where the team detailed each task within the project, each milestone, in microscopic detail. The business stakeholders didn't care about any of this, they just wanted to know when the project's deliverables would be transitioned into service and when they would start seeing a return on investment (ROI). This vital information got lost in the noise and the stakeholders created an unrealistic expectation that was different to what the project team had been trying to communicate.
The project delivered in line the project team's expectations, on time, on budget and delivering the business change promised but it was not within the false expectations of the stakeholders. This resulted in the project team having to engage in some pretty awkward conversations with disgruntled stakeholder clients who had misunderstood the over complex planning documents. You know the adage, "The customer is always right"? Having to tell them that they're not is never easy – especially when it’s kind of your fault they got the wrong end of the stick. K-I-S-S!
Avoid this by playing to your audience, deliver it in their language. If, as in this case, your stakeholders are business minded, deliver your plan to show you clearly understand business need, expectations and requirements. Ensure that they are documented in a way that cannot be misunderstood in your scope statement. Less is more!
3 - Keep it REAL
Realistic Expectations Allowing (for) Lag
When planning, you work backwards from project delivery and work out timings for tasks. You add these timings together and that gives you your project lifecycle. OK, that's a little simplified but that's pretty much it - but what happens to your project and by default your client or stakeholder expectations if something goes wrong?
The most successful project leaders and CIOs allow time in their project timelines for 'eventualities' and conflicts.
Say the project's task add together to five months, rather than agree five months with your stakeholder and communicate that to your team push for six or seven months. If the team delivers the project in five then they feel like rock stars, their morale is lifted, and you get to carry that confidence onto your next project and the best bit - your stakeholders think you're the best because you delivered with a month or two to spare.
Keeping it REAL requires being mindful of business needs and pressures. I mean, don't take the mickey, if the project needs to deliver to market in five months to compete with a rival, then it’s in your interests to bust a gut to achieve that.
BUT if you can buy some time it's a very wise investment.
4 -Update, update, update
The most important part of setting and achieving milestones isn't that you've set and achieved milestones. It's that you have communicated them with your client.
Many project teams see milestones as internal progress markers but actually, they are crucial for managing client and stakeholder expectations too.
If you hit the first few milestones late but advise your client, you can either assure them of steps that you'll be taking to catch up or begin to prepare them for later than planned delivery.
I was on a train recently that was a minute late leaving the first station, two minutes at the second and so on. The Train Manager announced each delay with an apology but what he failed to communicate was the impact on our final arrival. A near riot was about to ensue among passengers as they speculated and advised those collecting them from the station that they may be late. Then the guy explained over the loudspeakers that despite delays along the route we would arrive at our destination on time (the train companies are very good at point 3 and pad their journey times to avoid fines!!).
A final word on the bit about updating. Be honest when things go wrong - when it comes to managing expectations nothing beats the truth and the goodwill that this honesty generates (almost) always buys you some understanding should you hit further issues along the way.
5 - Pick your best team
It's amazing how far a client's or stakeholder's confidence in your team goes towards how they create their expectation of your capability to deliver. Breaking down tasks and knowing who, on your team, will perform them best and knowing who will work well together when required is a real skill; the better you become at it - the better your team will become at delivering successful, high quality, business case led projects.
If you identify a capability gap the Project Management as a Services market has an abundance of resources ready to plug straight in - so don't feel that you have to chance it. Allow me one last football analogy? It's like the difference between when a football manager fields a weakened team in a cup tie and they get hammered and knocked out of the competition, and when a manager fields his full strength team and they scrape a win. The benefit of the doubt from the fans is far more likely to be forthcoming following the latter scenario - and so it is with stakeholders of IT Projects. Always field your best team (and that includes drafting in external resources if you need to).
In conclusion, managing setting and managing expectations can be one of the hardest things to get right in IT Project Management but it’s also one of the most rewarding. Making sure that EVERYONE is always on the same page should be a priority for us all!
If you have any thoughts, ideas to add or you need some help with this in your projects, I EXPECT that you know how to get in touch.
Find out more about Project Management as a Service]]>
IT Projects are being choked and sometimes even killed by dysfunctional beliefs.
Simple as that.
Dysfunctional beliefs are neatly defined by the authors of "Dysfunctional Beliefs Affecting Stress" as having "to do with the actual content of thinking itself." Thoughts are powerful and over time become habits, in too many cases how teams think about the challenges they face is the greatest problem. My designer friends talk about reframing problems so that they are answering the right question and that's the challenge that we often face with our thinking.
My designer buddy Sam uses this example to demonstrate reframing.
Imagine you're at work on a cold, dark, wet November morning. It's raining so hard you can hear each raindrop smash against the corrugated iron roof of the office unit you are in. The wind is howling. You need milk from the local shop for your morning cup of tea. You're gasping for a brew but having tea without milk doesn't bear thinking about, I mean yuck!!! BUT You don't want to get your work clothes wet; who wants to sit in a soggy suit for the whole rest of the day?
What do you do? Most people start to think 'how can I get to the shop for milk without getting wet?'.
Take an umbrella? What about that wind?
Wear a raincoat? What about your legs? Soggy skirts and trousers are no fun!
You could run? Or drive? It's raining so hard that you'd literally only need to step one foot out of the door to be soaked.
The designer is minded to reframe the question so that it fits the actual problem. The problem isn't anything to do with the weather, or the shop, or even the milk. You're gasping for your morning cuppa remember - the outcome you want is to be drinking tea. The reframed question then is 'how do I get a cup of tea' - well it turns out that the local café delivers hot beverages and also has a really nice selection of cakes; perfect for a lousy morning!
Maybe some examples from the IT Project Management world will clarify this. Here are five that I've encountered recently.
1 - "Hiring in Project Management as a Service resources is costly"
A CIO whose project was about to sink said this to me, having reached out for help.
Two things here, first, the cost of not saving this project far outweighed any potential cost impact of taking action; the project was a key strategic business IT initiative and it was too important to fail. Secondly, often Project Management services can be accessed without net increases to your overall project portfolio budgets. It's worth asking the question at least. Your Project Management as a Service partner can help.
2 - "The buck stops with me, as a leader I have to cope with everything"
This is a bit of a throwback.
I think most of us remember a "my way or the highway" type of project manager, a macho, alpha male type who was a bit of an ogre. These days project leaders are different, we are mostly great at delegating and while it is true that, as the person driving the project, you have responsibility for keeping it heading in the right direction, a project's success should never rest on just one pair of shoulders. Delegate to your team and dip into the Project Management as a Service universe for extra resources.
3 - "There's no room to make mistakes"
EEEEK! The best lessons that I've learned in my IT Project Management career have been thanks to a mistake that I or my team have made. Messing things up should be a basic human right protected by the United Nations! Post It notes, microwave ovens, Penicillin, inkjet printers, and potato crisps were all invented "by mistake".
You should build in room for mistakes and make sure that you and your team learn from them.
4 - "The project is late"
Shhhh! Don't ever share this with your stakeholders; they won't appreciate it. The thing is - labelling your project as "late" is really demotivating. So, it's not late ... it's ... well, it's where it is. Once you have accepted where you're at you can deal with that!
Dave Evans, from the Product Design Programme at Stanford and author of Designing Your Life puts it nicely when, in a Stanford e-corner lecture, he asked students if they'd ever felt 'late'. "For what?" he asked. "There is no such thing, you're just here."
I love football when Manchester United played Bayern Munich in the 1999 Champions League Final they equalised after the ninety minutes had elapsed. Were they late? When Solskjær scored the winner three minutes into injury time was he late?
No!! 89 minutes into the game the reds were losing, they weren't late, that was just where they were and they dealt with it.
If you find that you are 'behind' and you realise it, then you can do something about it. Call your PMaaS partner and ask for suggestions, make adjustments to your portfolio and re-allocate resources, get advice from an expert at delivering projects into service.
Even a project delivered "late" is a project delivered. Cut yourself some slack!
5 - "I have to get all of today's tasks done today"
Yeah, in an ideal world, in a perfect workplace - you'd get everything on your stuff to do list done today. Life and work doesn't always run to plan, there are fire drills and "happy birthday to yous" to sing; there are phone calls and emails with red flags on them; there are power cuts and power struggles.
I worked with a guy once who used to (jokingly) say, "He who achieves everything today, gets made redundant tomorrow." It was his way of taking the stress out the fact that tasks were regularly getting passed forward to the next day.
I think that as long as you have a plan and a schedule for how you'll achieve uncompleted tasks tomorrow, you can tick them off today's list.
On a serious note, if you are finding that you are carrying many tasks forward every day, this may be a sign of insufficient resources. Again, having a fresh pair of eyes look over your workload can help and there are plenty of resourcing solutions in the Project Management as a Service market.
This week, try to watch your thoughts and assess them to see if they are serving you well. Make it a habit to play devil's advocate and challenge yourself and how you're thinking. Ask others for input, take views from people who are different from you and get an independent, fresh pair of eyes to take a look at your operation once in a while.
You literally would not entertain dysfunctionality in any other aspect of your project team, why should your beliefs get an easy ride.
Find out more about Project Management as a Service
So, how are your New Year’s Resolutions working out? Personal and professional?
Probably, if you're like most people I talk with, you’re having a mixed bag of results.
Now that's sort of OK with the personal stuff. If your resolution was to eat more healthily and hit the gym but you're still popping buttons off your shirt when you breathe out, well, you have time to make changes to your lifestyle.
If, on the other hand, your New Year Resolutions were professional it may be that failure to stick to them could cost you some IT Project wins.
I read that 80% of New Year’s resolutions fail by February. The reason? Usually, no commitment. Resolutions tend to be things that you THINK you should be doing, so quit smoking, take up running, meditate daily in your personal life or eliminate scope creep, set better KPIs, explore more efficient Project management as a Service (PMaaS) options in your work life. The thing is that these are all great goals but then along comes that nicotine craving on a stressful day or a key stakeholder with "just a small request" and often you cave in ... the path of least resistance is littered with broken resolutions!
If your resolutions are lacking a strong foundation of personal meaning and relevance the chances are that they won't deliver the difference that you intended. What you need is something much more fundamental and important to you because when your resolve comes from the inside, based on something that matters to you or genuine past pain, you have a much greater chance of seeing it through.
With this in mind, this year instead of New Year Resolutions, a few of my IT Project friends have made New Year Pledges. They're more specific and measurable than resolutions and because they are based on actual pain points it will be interesting to see how effective they are. Here are some of them.
1 - Clarity on Responsibilities
Martha's team are big on delegation but 2018 has thrown up issues around clarity on who is responsible for what. "Three or four times there were instances where something would need attention and when we looked for the right person to sort it - no-one knew who that was!!!" Increasingly, Martha's projects span different offices, even different continents and this is making it even more important to nail down who is doing what! It sounds really basic, but she is not alone.
Specifying which team member is responsible for what task and making them accountable for it is a key pillar of project success. Martha has invested in a real-time task management system that can be accessed online and it should do the trick but there are many options available from the PMaaS universe that can also help organisations stay on top of task and resource management.
2 - Full Project Details - Up Front!!
Ensuring that you have full project details before you start may seem like an obvious call but, according to Martina, a project scope, fully approved by all stakeholders, isn't always the foundation upon which IT projects at her organisation are built.
The more detail your initial project brief and documentation have, the more chance you have of succeeding. You wouldn't build a house without first getting an architect to draw up the plans!
Martina's pledge for 2019 is to refuse to start a project until milestones, budgets, deliverables and delivery dates have been signed off and agreed by key stakeholders.
3 - Stay Focussed on The Why
Martin's pledge for 2019 is also based around scope creep.
"2018 was the year of missions getting sidetracked by requests from stakeholders that could and should have been totally separate projects with separate budgets and timelines to go with them," he told me. "It's been like we're baking a Victoria sponge cake and the stakeholders have come into the kitchen and said, 'You know what would be nice too? Shepherd's pie!' We need to be better at saying - that would be nice but right now we're baking a cake."
Martin's pledge is to remain focused on the why. The reasons you initiated the project and the business case for it. "We'll accommodate change requests when they support the why. If you want a sprinkle of icing sugar on top of the cake - you got it! If you want minced lamb, gravy and mashed potatoes then that's a new project so, don't be offended if we ask for a new budget."
4 - Motivated Milestones
Kyle has pledged to keep project team members motivated by rewarding them when individual milestones are reached. "I noticed that we're really good at cracking open a bottle of bubbly when a project is delivered into service but successfully completing chunks of work, the cornerstones of a successful project, tends to pass uncelebrated."
"Teams can decide what reward they'd like, within reason, chocolate has been the runaway favourite so far, but one team has a night of ten-pin bowling riding on the successful completion of their current task. We've put a bell in the office and that gets rung by the team when they win their reward. We trialled the initiative since about September and it is helping keep track of individual work parts as well as inspiring better performance!"
5 - Be Break Aware
All of the booze bottles I opened over Christmas had the words "Be Drink Aware" on them. This, apparently, has inspired Hannah to be "Break Aware".
"It was a dark, late November afternoon when I realised that I'd not moved from my desk and taken my eyes off my screen for more than three hours," says Hannah. "It dawned on me that for probably half that time I'd been operating on autopilot and not giving my work my best attention. I looked around my team and we all looked exhausted!"
Does this sound familiar? I mean I've been writing this blog since just after breakfast on and it's now nearly lunchtime - I haven't shifted from my seat, my eyes are tired and spell check keeps underlining my mistakes with a red wobbly line. Now, this is just a blog and doesn't matter in comparison to an IT Project that I may be working on when I return to the office. Then my performance WILL matter and could be the difference between success and failure.
Hannah's pledge is that she and her team will work in 30-minute bursts and after each one, a short refresh break will be taken. On that dark November day Hannah took a walk out onto the street outside and felt the rain on her face, I've just taken a stroll around the car park and inhaled some fresh(ish) air!! A short break re-energises you! And yet many of us don't take them!
It's no wonder IT Project work can be so stressful at times, we're running on pure caffeine. Take a break. Take a deep breath. Your project will thank you for it.
So, there you have it, pledges may be better than resolutions. Time will tell. Let me know if you’re pledging to make some measurable changes in 2019 – I would love to hear about them and help you achieve them in whatever way I can.
Find out more about Project Management as a Service
The project had cutting edge visibility so the "random" occurrence in question could be acted upon quite quickly and corrective action was taken before anyone even really knew there was a problem. It meant a later night that Friday though!
The Project Manager sighed, "Oh well, the unpredictable stuff is what makes an IT Project interesting, right?"
I admire that philosophical viewpoint, but personally, I like starting my weekends on time. I wondered ... is anything really random and unpredictable in IT Projects? Could this have been avoided?
Randomness and IT Projects seem, unlikely bedfellows, I mean, a computer's output is dependent upon input - that's what GIGO (garbage in, garbage out) was all about! So it is with IT Projects. Do we just need to get better at identifying when garbage has gone it?
Tech journalist, Bill Thompson told Radio 4's The Curious Cases of Rutherford & Fry, "Computers don't do random ... they are a designed to be predictable and the best we can achieve within a computer is what we call pseudo-randomness where you have a complicated seed number that is supposed to be unpredictable and then an algorithm which takes that seed number and generates from it numbers which are supposed to be random. The problem is if you repeat the seed and repeat the algorithm you'll get the same pattern of numbers out." You could illustrate this for your self - if you opened an online random number generator, and analysed results, over time you'd start to see a pattern emerge.
So, how can you spot patterns that emerge within your IT Project? How can you start to predict IT Project Management 'random' outcomes - before they cause problems?
To find the answer, forget the online random number generator - let's go analogue!
Roll with me on this (pun intended).
Do you have access to Monopoly or Yahtzee?! Grab the dice, pick a number between one and six and roll them - repeat, repeat, repeat. How many times did you predict the right number? What this demonstrates is the apparent randomness of dice rolling. Dice are, after all, meant to introduce the element of random chance to whichever game you are playing. Who hasn't been six Monopoly spaces away from jail, rolled a double three and exclaimed, "What are the chances?!"
What if I told you that even dice rolling were not as unpredictable or random as it seems? The throw of a die is, after all, governed by Newtonian physics so if you could have access to data like the speed of the throw, the starting position of the die and the thrower's hand, the weight of the die, the air pressure in the room, you could, in theory, predict what number would result from your roll.
Actually, researchers at the Universities of Aberdeen in Scotland and Lodz in Poland created a sophisticated theoretical model of a die throw (in their study The three-dimensional dynamics of the die throw). They filmed the die with a high-speed camera and considered influences of gravity, air resistance, the friction of the table, and other factors and assessed which of these could most affect the outcome.
What did they find was the most important factor?
"The initial position of the die," Tomasz Kapitaniak, from the University of Lodz told Inside Science's Ben Stein.
There's the lesson for IT Project Management ... the secret of predicting 'random' outcomes lies in knowing the initial, starting position.
So, back to that IT Project that delayed the start of a weekend.
The Monday after the Friday before, the Project Manager and I had tracked back looking for a trail. We were searching for a missed red flag that might have allowed earlier identification of this "random event" in the future. It didn't take long for us to find the exact moment where the problem started - the initial position. We traced that Friday afternoon bug back to an inadequately tested software component developed weeks before. It had been tested back then, warning signs had been missed and as the software development life cycle continued this one component had become increasingly unstable until, eventually, it fell over.
Finding the "initial position" of a problem allows you to correct it and also adjust your processes for the future. In this project, continuous testing of smaller component parts as they are being developed will ensure that this doesn't happen again. The cost of fixing issues in later stages of an IT project is usually much greater than the cost of fixing sooner, as you go along, so it makes business sense to work this way and keep project costs in control. This team had just got busy and missed what their testing had been subtly trying to tell them. They won't do that again!
As IT Projects become increasingly complex and crucial to your organisation's strategic business goals, it's important that we all get better at predicting the unpredictable. It can help to have a trusted IT partner run an independent pair of eyes over your IT Project issues and you can buy in end to end Project Management as a Service (PMaaS) solutions that bolster governance and transparency. This will make "random" problems less likely or, at least, easier to track back to. Ultimately though, IT Project teams must accept responsibility for the "unpredictable" because, frankly, nothing is really unpredictable, just unpredicted.
Find out more about Project Management as a Service
PS. Looking for a Project Management Read? How about our newly launched E-Book full of Project Management blogs? Download your FREE copy
An IT Project Manager I know, let's call him Richard, has just had the biggest run of bad luck that I've ever seen while delivering an IT Project. You know those online lists of things that can sink a project? Well, Richard's project has checked them all off one by one. It's been enough to consider throwing in the towel on an almost daily basis, there was "sign" after "sign" that luck wasn't with him. Many other PM's I know would have given up, many other CIOs would have pronounced the project dead and a drain on resources - it did look holed under the water line! The problem was that this project added key strategic value, the business case was indisputable and future projects were entirely dependent upon it.
By the way, that quote from Michael Jordan is from a poster in Richard's office.
This week, Richard delivered his project just a week and a half late and only a fraction over budget.
Richard, the unlucky Project Manager, doesn't even see himself as unlucky! He relishes the challenge that failure brings and the opportunity to learn and try something new.
The truth is that most successful people have more failures than average because they do more. They ideate more, they try more, they challenge themselves more. When it goes wrong, they pick themselves up, and dust themselves down, they learn the lessons that failure has taught and shake off negativity quickly. Contrast this with others who dwell on the mistake too long, or commit to make the failure the last thing that they do in the project and it's easy to see how response to failing is the difference between victory and defeat.
I've always maintained that once a goal is clear you cannot let 'failure' and distractions get in the way. You cannot be swayed by criticism or what people "want to hear" – you have to stick to your guns - never stop at a failure, keep going until you get all the failures out of your system until the only possible outcome is success.
I love the quote from Thomas Edison about his "failure" to invent the light bulb. “I have not failed 10,000 times," he said, "I have not failed once. I have succeeded in proving that those 10,000 ways will not work. When I have eliminated the ways that will not work, I will find the way that will work."
Smart man Edison! There could be a lot in his mindset for Project Managers. Moving quickly to prove that an idea is not going to work, allowing you to side-line it and shift focus elsewhere can only speed up success, right? So ... how to apply it?
Here are Four ideas on how to Fail Fast, Fail Often, Fail Well.
1 - Ask An Independent External Pair of Eyes To Take A Look
Working hard in your project, it can be hard to spot when things go off course, take a view on what's going wrong and what to do to correct it.
Often, a trusted IT Project Management partner can walk into your project and instantly spot things that you have become blind to and advise timely corrections.
One of my PM friends compares this with the home improvements that he made when he sold his last house. He'd lived there for seven years and there were a few jobs around the place that he'd been ‘getting around to’. One, in particular, was that he had installed the wires for a shaving light above the mirror in the ensuite bathroom, but never bought the light! Over time, he had become blind to the wires hanging out of the tiled wall with their ends sealed with coloured insulation tape. Every potential buyer saw them though and couldn't see past the protruding wires to take in what was an otherwise show-home quality bathroom.
2 - Get Good At Quick Action Evaluation
When an IT Project takes a wrong turn and you take corrective actions - how good are you at measuring the effectiveness of those actions?
Many IT Projects flounder not because they fail to identify an initial problem but because they fail to monitor how well their interventions work.
A PM friend, Martina, implements a great 'measurement cycle'. Firstly, she believes that 80% of solving a problem is becoming aware of it and having the willingness to tackle it! At this stage, she says, the hard part is over so she treats her team to cakes or something like that as they gather to work out the solution.
At this meeting, the team is encouraged to believe that they are free to ideate, they are not trapped by preconceived ideas or 'what's worked in the past'. At this stage, the mission is to increase potential with extremely positive, empowering language and thinking. This freedom allows some really creative solutions to be suggested, like seeking ideas from the Project Management as a Service sector. Martina considers this stage to be about 15% of the overall process and it is here where the real genius lies.
95% of the work is done. The pressure is now off!!
The corrective action and measurement of the success of that action are only 5% of the total process effort, 1% for the action and 4% for analysis of the result of the action!
Firstly, this allows the team to move bravely forward and implement the action - and be totally honest about how well it has worked.
Secondly, and this where the "cycle" part comes in, the team is encouraged to evaluate quickly and if necessary get back to the start of the process again where awareness and willingness kick-start any necessary further actions.
3 - Pre-Mortem Beat Post-Mortem!
You'll have heard of, and probably, done a post-mortem where you look back at a project after it has failed to find out why.
What if you could predict in advance why a project is likely to fail? (Google) X's Astro Teller often talks about pre-mortems. At X, teams vote to kill their ideas in advance - pre-mortem. The thinking being that the ideas that survive this process (those ideas you literally can’t kill) are the ones worth pursuing.
I have seen this work really well in IT Project Management where the Project Team have emailed stakeholders and end users, explained what the goals of a project are, how it will work, what it will deliver and then asked ... "A year from now, this project has failed - why?".
The feedback the team got from this was invaluable. Once they had identified and filtered out the change-resistant negative gripes, they were left with some really useful insight that undoubtedly allowed them to "see around a few corners".
4 - Get Good At Flagging Up Issues
When a culture evolves where everyone has the right AND the responsibility to flag potential issues it's amazing how much more quickly they are dealt with, accelerating success.
The textbook example of this is Toyota's 'Stop the Line' manufacturing technique, in which every assembly line employee has a responsibility to push the big red button that stops everything when they notice something that they are not happy with. When this happens supervisors rush to the source of the issue and the first thing they do is thank the employee who pushed the button. By fixing problems as they happen what you maximise your response options and improve your process.
Too many IT Projects still have a culture where you press on and anything less than full steam ahead is not acceptable. Sometimes, most times, you get there quicker by occasionally stopping to check that you're on the right route! Taking a helicopter view once in a while and encouraging all team members to holler if they feel that something isn't right has saved many projects from costly problems.
That's just four thoughts on how to, as the title says, "Fail Fast, Fail Often, Fail Well". As the second half of the title says, "The Key To IT Project Success" is in how well you fail so I would love to hear any thoughts or any tricks that you have and, as always, if YOU need that independent second pair eyes, please get in touch.
Find out more about Project Management as a Service
PS. Looking for a Project Management Read? How about our newly launched E-Book full of Project Management blogs? Download your FREE copy]]>
Basically, it's like 'This Is Your Life' (if you remember that back in the day) but instead of celebrities coming on and praising the subject of the show, they turn up and spill the beans on their bad habits and worst moments. The most recent one I saw featured Bruce Willis and Demi Moore was hilarious roasting her ex-husband.
I wondered what kind of stories would come up if they did an episode entitled "The Roast of A Project Manager" and so asked a bunch of friends and colleagues in the industry. Their replies made me smile and actually read like a handy list of mistakes to avoid when managing an IT Project!
Get in touch and tell me the stories that would make you cringe if you appeared on "The Roast of You" and in the meantime … enjoy …
The Roast of A Project Manager
1 - Big Project / Little Experience
A couple of PMs messaged me back to say that they had once bitten off way more than they could chew - the result - they choked!
Matt emailed to say, "It was my third IT Project, the first two had been runaway successes and I thought I could take on the world! I was wrong! I took on a project that was way too complex for my experience level and it very quickly started to teach me lessons. The greatest lesson that I have kept with me throughout my career is to be humble and if I think that something is beyond me or my team - ask for help! Over time my experience and confidence have grown but I am still mindful of not stretching my team's resources in a pointless show of bravado! The Project Management as a Service sector is like a magic genie of resources!"
I wonder how many other PMs would expect this to crop up on their "Roast Of …"? Matt's lesson from those early days of his career is one that we can all take note of. In my experience, project sponsors, stakeholders and CIOs are much more receptive to honesty upfront about a capability gap than they are to the news that your inexperience has caused the project to fail.
2 - Lack of Business Case Clarity
Julia messaged me to recall the IT Project that she once initiated with only a basic understanding of the parent organisation's needs. "It didn't end well," she remembers.
"To be fair I was pretty new at this firm and less confident about confrontation than I am now. The brief was so full of holes it could have been used as a colander! These days I'd push the brief back, ask questions, insist on a proper document that detailed requirements. Back then I just thought, OK, I have some information, I'll have to fill the gaps for the rest!"
Filling gaps in a project's business case needs is an easy trap to fall into. The best you can hope for is that you nail it but even in this case how much credit do you think you get? You can't say, "Hey look at this project I delivered despite the lousy brief." That never goes down well! Worst case scenario is that you get it wrong and the project fails to deliver on its business needs - suddenly the credit for this is all yours!
No, Julia is right, if the brief doesn't spell out what the project should deliver for the business keep sending it back until it does!
3 - Inadequate Initiation
Malc wrote to me to say that he shudders at the memory of an IT Project which started without a proper starting plan in place. "I mean," he writes, "Everyone knew what they were doing. It wasn't the most complex IT Project ever. We all agreed to crack on."
"Cracks started to appear when two team members got their wires crossed about their responsibilities. Soon roles got blurred, project milestones weren't defined and so got missed and finally, the delivery deadline date had to be pushed back due to the rather slapstick way that we were operating."
A project initiation meeting is vital so that everyone sets off in the same direction at the same time! What's that old saying? Proper planning prevents poor performance .. so true of IT Projects! I honestly think that it could be the most valuable time that you spend on your IT project, a chance to double check that everyone is sure about their role and what the project is meant to deliver.
4 - Scope on A Rope - A Bungee Rope!
At some time, who hasn't had scope creep rob them of project glory?
Lydia emailed to tell me about the project that taught her the value of saying 'no'.
"We started off with a tightly agreed project scope, everyone seemed fully bought in and engaged and REALLY friendly. Then a lot of afterthoughts started to surface, a lot of requests for things that would 'be kind of nice' to incorporate and each of them had a sound business justification. There was no procedure for assessing scope change requests and as each was fairly inconsequential in terms of budget and delivery date we waved them through. The problem was that although they were inconsequential in isolation they added up and we blew the budget!"
At this point, it's amazing how all the people who emailed their ideas for bonus project extras seem to disappear leaving you, as Project Manager, to carry the can.
Lydia says, "Once bitten! Every project I ever worked on since has had a procedure for scope change requests and assess them based on their business case, impact on budget and how they'll affect delivery."
It was interesting that most of the replies I got referred to mistakes that happened in the dim and distant past. Experience teaches great lessons and I think that, in IT Project Management, we are constantly learning.
One of my major passions, the Project Management as a Service sector, is a constant teacher and is expanding to levels where there is a solution for just about every issue that could potentially lead to a project failing. It is certainly worth exploring if you have a challenge. Then, if they do ever make ‘The Roast of a Project Manager’, at least it won’t be about you.
Find out more about Project Management as a Service
PS. Looking for a Project Management Read? How about our newly launched E-Book full of Project Management blogs? Download your FREE copy]]>
It's one of those questions that you answer instinctively - great organiser, they deliver projects within deadline and budget, good communication skills, etc, etc. All true but I was a little disappointed by my instinctive, off the hip answer - I mean these are all pretty basic role requirements … PM's who can't communicate or organise don't last long!
The thing is, I have had the pleasure of working with some rockstar Project Managers! So, I gave this question some more thought on the drive home and then emailed a more satisfactory response to the CIO who posed it and I thought I'd share it with you too!
I'd love to hear from you … do you agree or disagree? Is there something that I have missed from …
THE SEVEN KILLER TRAITS OF A ROCKSTAR PROJECT MANAGER
1 - They Have an Entrepreneurial Streak
More and more I am seeing Project Managers with a real entrepreneurial streak who are running projects like micro businesses within their parent organisation. There are of course huge advantages to this trait, not least that projects tend to come in within budget when run they are subject to a business-like level of scrutiny. Beyond this, though great entrepreneurial Project Managers are spotting extra revenue opportunities both within their current projects and in the wider business.
In the same way that Sir Richard Branson surrounded himself with brilliant people, entrepreneurial Project Managers build great teams of complementary talents within your company. Entrepreneurial Project Managers are instinctively driven to build and manage great teams and also to deliver innovative products.
2 - They Are Fabulous People Managers
Actually, I think that this a trait that sets Project Managers and Project Leaders apart. Great managers manage things, great leaders lead people.
Watching Gareth Southgate at the 2018 World Cup perfectly demonstrated the latter, the way he connected with his team as individuals and seemed to know what made them tick should be an inspiration to anyone tasked with building a team.
One of my PM friends who falls neatly into this category has an intense dislike of the term 'human resources' and actually successfully campaigned for his firm's position of HR Director to be rebranded Director Of People.
3 - They Roll Up Their Sleeves/Have Experience Beyond Project Management
A CIO once told me about his favourite Project Manager. This guy didn't merely manage the project he did his best to live and breathe it by rolling up his sleeves and spending time in the places where the project would have an impact. He observed the processes and working practices, he got to know the typical characteristics of the end users and asked their opinions. Once, he even spent a morning working manually on the factory floor to get a true end to end sense of the effect that a project he was managing would have. This is exceptional and you may not have time to do this but gaining experience beyond Project Management duties gives a manager valuable new perspectives and insights.
4 - They Are The King/Queen of Collaboration
Collaboration may be the single greatest weapon in an effective project manager's arsenal.
Firstly, there's collaboration within the team. A great project team leader inspires a sense of togetherness and has the ability to identify points of contention, intervene, find a solution and keep the project running in its intended direction of travel.
Secondly, there are the extended collaborative benefits that an independent project management services partner can bring. Great leaders know when they need talent and resources to complement their in-house team and they know where and how to find them. The Project Management as a Services market has infinite collaborative opportunities and the greatest PMs either know how to choose what's right or they collaborate with a services provider who will.
5 - They Know How to Eat A Whale!
"How do you eat a whale? One bite at a time". I love this saying. There was a poem by Shel Silverstein that I read in one of my children's books years ago that went "Have you heard of tiny Melinda Mae, who ate a monstrous whale? She thought she could, She said she would, So she started in right at the tail," and it goes on, "She took little bites and she chewed very slow." IT Projects are like this - huge monstrous projects can only be achieved by breaking them down into bite-sized, easy to manage pieces. The best PMs can instinctively reduce complex projects into achievable work units.
6 - They Are Great 360 Degree Communicators
Communication skills is a given, but a major difference between good and great project managers is their ability to communicate with colleagues at all levels. Effective project leadership needs clear communication.
You have to communicate with your team about their responsibilities, the project's goals, performance expectations, and of course you must be able to give meaningful feedback that can be acted upon.
Beyond this, of course, you also have to communicate UP! The finest Project Managers are great negotiators. They tell stakeholders and project sponsors what they need to hear as opposed to what they think they want to hear - the difference between these can be the difference between success and failure. They are not afraid of rank and have the same confidence communicating with an end user of their delivered project as the organisation's CEO.
7 - They Are Problem Solving, Decision Making MACHINES!!!
The average IT Project throws out problems to be faced and decisions to be made by the bucket load. Have you noticed how some PMs instinctively know what to do … and they just do it?
The quality of decisions can define the progress of your project, one false move and you can be in real trouble - how often has a single decision, seemingly minor and irrelevant in nature, put an entire project in jeopardy?
So, there you go. The 7 Killer Traits of a ROCKSTAR Project Manager - A CIO's Checklist. Have I missed anything obvious? Do get in touch with any thoughts and if you need Rockstar project management (as a Service) for your IT projects … I'd love to help you with that too.
I really enjoyed thinking about what makes a great PM - meditating deeply on the question made me feel grateful for the wonderful talent that I get to work with and hugely appreciative of the work I do … and maybe that is the bonus eighth trait of a rock star Project Manager - whatever the ups and downs, whatever the challenges … they LOVE IT!!
Find out more about Project Management as a Service
PS. Looking for an easy holiday read? How about our newly launched E-Book full of Project Management blogs? Download your FREE copy and take it away with you!]]>
He clearly never had to manage an IT Project in an organisation resistant to change. I think we've all experienced some of our darkest hours doing this.
I was chatting to a PM friend this week and he joked that the organisational culture where he was currently employed was so resistant to change that if all the staff were on a train and it was announced that, for their destination, they should change at the next station - they'd stubbornly stay put and end up miles from where they needed to be.
Some organisations are like this, aren't they? Time and again, Project Managers are told to go and initiate strategic change only to find brick wall after brick wall.
The thing is, change is inevitable. In business, you either adapt and innovate or you die.
Most businesses are now dependent on IT so it is increasingly the responsibility of IT to drive business change and for many, this is a truth that hasn't been accepted. Amazingly, some businesses still see IT as a back-office support function, they seem to be wondering, "What the heck are the guys who come and turn PCs off and then back on again doing facilitating business change?" For strategic change to have the most impact, organisational cultures have to have evolved in line with this reality. Some have and some REALLY haven't!
Writing for ProjectManagement.com, Michael Wood says, "Most OCs [organisational cultures] grow and evolve over time. Often, they are an extension of the founders’ own values and beliefs. Other times, they are a collage of influences and practices that have just become the way things are." It has never been more important for IT project teams to challenge this status quo, as Michael puts it, "the way things are" to leverage the greatest benefit from a change programme.
1 - Know Your Own Culture
I heartily recommend Michael Wood's article for many reasons, not least because he rather usefully identifies a number of different business cultures from "Clan Culture" ("Friendly, family-like culture where people share much in common") to "Hierarchy Culture" ("Formal and structured; processes and protocols drive how people work and interact") and he suggests that different mindset is needed in each case.
Michael highlights about four cultures, in my experience, every business has its own unique culture and style and each different culture needs a different approach when it comes to managing change - just as you'd interact differently with your children if one were a teenager and the other a toddler.
Approaching Michael Wood's "clan culture" model with a copious amount of data that proves the need for a business change would be as ineffective as turning at the "hierarchy culture" with your jacket slung over your shoulder and saying, with a winning smile, "C'mon guys - trust me on this."
You need to know your culture so that you know how to interact with it, when we provide Project Management services it is one of the first things that we do - we get to know you. I can't imagine operating in any other way.
As Michael Wood puts it, "When a PM meets with extreme resistance to change, they may be experiencing a disconnect between their approach and the type of culture they are in. This is why assessing the culture in terms of what drives its definition of “good” can help the PM avoid such disconnects."
2 - Friends in High Places
It has never been more important for clear and decisive leadership engagement throughout the lifecycle of an IT change project. That is not to say that the project sponsor needs to oversee the whole thing, but project managers do need a senior touch point in the event of an impasse. In my experience, this can come in the form of an actual physical person who can be called upon to flex some leadership muscle or as a clear document of intent that spells out the change and its importance to the business.
Whatever form it takes, little shifts resistance to change like the fear of ending up on the radar of your company's leaders. Business case is the most important thing for any IT Project, it is a PM's responsibility to ensure that a project’s and its parent business' goals and objectives are aligned. The greatest way to achieve this is to ensure that it is the business leadership - those that set the operational culture - who communicate this or, at least, openly back it!
3 - Engineer "Group Get It" Moments
When you have a group of people who perform similar roles or have a shared process at the heart of their workday, it's amazing how quickly you can convince all of them of that a change is needed by first convincing one of them. It's not that they're sheep but YOU are an outsider! Think about it - who are you coming in telling them that there's a better way of doing what they do every day? I mean - the cheek of it, disrupting their lives like this! However, when Sandra in sales order processing gets it and becomes an ambassador for your change you'll find the rest will try harder to understand. Ultimately, if you can convince users that the old status quo is no longer fit for purpose and that the change is a new, better status quo then they are usually less resistant to change.
4 - Independence Carries Less Baggage
Almost paradoxically, while you may be seen as an outsider, an actual outsider may find it easier driving change in a change-resistant organisational culture.
While the finance guys may consider you an outsider, actually, you probably share the same water cooler or canteen. In other words, you have to work with these people and, in my experience, sometimes that is in the back of Project Manager's mind when considering a more confrontational approach.
When you use talent and resources from the Project Management as a Service sector, i.e., when change is being driven by someone who won't have to stand in line for a coffee, this is much less of consideration. Resistant end users are more likely to throw a spanner in the works when they feel comfortable doing so, in other words when they know the person driving the change - familiarity breeds contempt.
There is a lot to be said for a fresh pair of eyes!
5 - Clarity of Purpose Is King
It sounds obvious and, of course, you would never start an IT Project without being clear on the intended outcome ... right?
That clarity has to be taken to another level when dealing with a change-resistant culture. The slightest chink in the stated goals of a project can wreak havoc. If there is the smallest doubt - the change-resistant will jump on it - and doubt spreads fast. To leverage maximum project success objectives are not flexible, goals and non-negotiable and this has to be clearly and authoritatively stated at the start and throughout by the organisation's leadership.
If you’re driving change in a change-resistant environment, I hope that this helps, and I would love to hear any ideas you have.
Philosopher Friedrich Nietzsche once said, “The snake which cannot cast its skin has to die."
Inability to facilitate strategic business change inevitably has the same impact on your organisation. In IT-dependent organisations, (i.e. most) it is the responsibility of the IT leadership to make change happen, for many this is a new skillset, for many more it is a natural extension of existing ones - whichever category you fall into getting better at driving change against resistance or having a contingency plan with a project services partner is well worth it.
Resistance is fatal.
Find out more about Project Management as a Service
In this blog we explore ...
5 Causes of IT Project Manager Nightmares - And Solutions For A Good Night's Sleep.
1 - Staff / Resource Shortages
In the case of staffing levels, as anyone who has managed a project through the flu season will confirm, this can happen suddenly. You can be left with having to re-allocate tasks at very short notice which can lead to overworked talent and overloaded resources. Then, there is the altogether more predictable and yet, surprisingly, even more common ‘deadline to resources available ratio’ - when you have two days, ten jobs and an exhausted team of four to do them.
Explaining the situation to stakeholders and requesting more time is an obvious, yet underused, strategy in these circumstances - they'll usually respond with understanding.
Furthermore, the Project Management as a Service market has talent and resources on tap to help cover any shortfall you have and you should broker a relationship with a partner before they happen. Choose someone who will get to know you and how your work and your projects and portfolio so that when all your staff do call in sick or that deadline looms, they can be ready to hit the ground running.
2 - Loss of Control
A common cause of PM insomnia is the feeling that you don't have control of your IT Project. This usually happens when there's a lack of transparency into the project when team members aren't updating the collaborative software or are working in silos and not communicating properly or relying on one team member to collate project information.
When you read back the list of reasons the solutions are obvious aren't they? Knock down the silo walls, introduce collaborative Project Management tools and train your staff how to use them and why they must. It can be easier said than done though! Taking a regular helicopter view of your project can give you a feeling of control, alert you to future roadblocks and give you time to prepare for them. End to end Project Management Office solutions are available to parachute in extra governance and control too - ask your Project Management services partner.
3 - Lack of Space to Breathe
Have you ever put in place the perfect project plan, hit every milestone along the way only to find that a last-minute spanner in your works throws everything off course? Often Project Managers tell me that they're worried that there is no space for error in their planning and usually it is because they have agreed to unreasonable stakeholder requests or expectations.
You should always build wriggle room in both your timescales and budgets - do you always have a contingency budget? Expect and plan for the unexpected.
Your trusted Project Management services partner can provide an external, independent fresh pair of eyes that can spot potential bottlenecks in your planning.
4 - Prioritisation Elsewhere in The Portfolio Delays Your Project
One of my PM friends called me recently almost in tears. The project he was working on was on time, on budget and had already delivered on key business promises when another more urgent project landed in their in-tray. And ... you'll love this ... the team were expected to keep the original project on time too! The stress that this had caused was immense, I'm clenching up just writing about it!
"What can I do?" he asked. But he already knew, he had to control what he could control, reassign tasks, understand and manage the stress of her team and communicate the reality of this major change to the plan to all the stakeholders. I also told him to investigate extra budget to graft in Project Management as a Service talent. When he did all this it was generally agreed that to deliver both projects - extra funding would be needed for complementary talent.
5 - Am I Making the Right Calls?
Project Management can be a lonely pastime sometimes and even with all your experience and knowledge you never really know if you're getting it right until you hand over a successful IT Project.
A PM friend called me with a different angle to this anxiety. He didn't know whether his boss or project sponsors knew the calls he was making and whether they understood the decisions or thought that they were the right calls!
Usually, from either angle, this is addressed by proper documentation of decisions. When you can look back on the stimuli that led to the decision you can quickly dismiss any anxieties and reconfirm, in your own mind, the validity of the call you made. Also, you can demonstrate the thinking to your seniors or stakeholders, if needed.
Collaborative tools and working practices also help - when your team is keeping the central project database up to date you are dealing with transparent, real-time issues. Less guesswork - however, informed and based on experience it is - is always a good thing. Like playing poker with a full deck rather than the one where the dog chewed the ace of spades.
The Project Management as a Service market has talent and resources on tap to help with most IT Project anxieties and, to repeat advice from earlier, you should broker a relationship with a partner before those sleepless nights start. Choose someone who will get to know you and your projects so they can be ready to hit the ground running.
It's true, isn't it? The more passionate about a task you are, the more likely you are to succeed. Even doing the dishes can be a chore or a fun twenty minutes reviewing the day with a loved one. Same with IT Projects!
I've been involved in some REALLY exciting IT advances. Don't get me wrong, I've always brought my A game and been REALLY proud of the delivered project and then, strangely, found myself getting EVEN MORE excited about the next project that had a less 'headline grabbing' outcome. I know I'm not alone because a friend just emailed to say that of the two projects his team were handling, a 'sexy new app' and a 'keep the lights on' system upgrade, he was more excited by the latter. What's that all about?!
I've often been asked what it is that gets IT Project talent out of bed in the morning. What drives us to search out seemingly hidden meanings in oceans of project data? What spurs us to burn the candle at both ends, to pull late nights and long weekends to miss nights out with friends and nights in with the other half? I've also often joked that if we could work this out, bottle it and sell it - we'd be millionaires! So, let's have a go at this.
By chance, recently, I happened across a concept that I first heard about in the 1990s and which, I think, may hold the key to why some projects inspire more than others. The information gap theory of curiosity.
The information gap theory of curiosity was developed by Professor George Loewenstein of Carnegie-Mellon in the early 90s. Essentially, Loewenstein believes that curiosity can be boiled down to the emotional reaction you have when you identify a gap between what you know and what you want (or need) to know!
Einstein once remarked, "I have no special talents," adding, "I am only passionately curious." Was Einstein on to something? I think that this "passionately curious" tag applies to everyone in IT Project Management most of the time ... but not always! So, why are we more "passionately curious" about some projects than others?
It could be that size matters.
I'm not thinking about the size or complexity of projects, although it is sometimes nice to have a big meaty project to sink your teeth into - that's not always enough to spark a PM's passion. Thinking back to Loewenstein's theory, could it be that how passionately curious you are about a project is directly related to the size of the gap between what you DO know, and what you NEED TO KNOW to deliver it?
Paraphrasing Loewenstein, we tend to be more curious about things when we feel close to the answer ... but not quite there. Therefore, if you feel that delivering a project is a walk in the park, you may be slightly less animated working on it than on a more cerebrally challenging project, even if that project's outcomes are less likely to set the world alight!
Similarly, extending Loewenstein's theory in the other direction, where a project is totally and utterly beyond your current capability and experience - it's maybe even easier to see how you might fail to keep up a sense of passionate curiosity when the information gap is too great.
Talking recently on a Radio 4 documentary about (of all things) Mars, Professor Loewenstein remarked, "People tend to be most curious when they know a lot about a topic but there's some kind of salient question that remains unanswered. That’s sort of a sweet spot for curiosity. If you don’t know very much about something you don’t tend to be curious and of course, if you've answered the question, you're no longer curious - because you have the answer!"
So, this could be why you get passionate about some projects and others ... well ... not so much. When a project tests you, challenges you and wakes you in the night with 'eureka moments' but you know that delivery is within your capability, you are much more likely to apply your curiosity muscles to it than when you're way out of your depth, or coasting to a hassle-free delivery.
As Loewenstein says, "The perfect gap is where you know a lot but there's still a well-defined unanswered question. In the case of Mars there's a lot of questions but certainly, the number one question is whether there's life there or has been life on Mars in the past. It's a very ... salient information gap for a lot of people."
That salient gap may be the key!
I suppose when you know a lot but not quite everything you can, with some confidence, fill in the gaps from yours or your team's knowledge bank. You fill in gaps with hypotheticals, informed estimations and experience led guesswork. That must also drive curiosity ... you want to see if you were right (even though you're pretty sure you are because you made the call with the safety net of past success). The larger the information gap the more any guesswork becomes less of a calculated risk and more of a gamble.
Thinking about all this, I am wondering if the information gap theory of curiosity could be the root cause of problems with most failing projects, that I am asked to consult upon and attempt to rescue. I mean, I have seen projects where complexity and size are way beyond the experience of those tasked with delivery and failure could (and should) have been predicted, but there also projects that fail where you'd think that successful delivery was WELL within the team's capability. It's a bit like when a league leading football team beats everyone in the top half of the table but loses against the side fighting relegation.
I think that we have stumbled upon something here but how do you apply the information gap theory of curiosity to IT projects? What can you do when you risk either complacency because a project is too safely in your comfort zone or wild guesswork when it's way, WAY outside? The regular reader will expect me to point to Project management as a Service for the solution and I'm not about to disappoint. After all, if there's one thing that I am passionately curious about it is the ever-expanding universe of answers that is the PMaaS market.
It might be obvious to point to the big information gap projects as candidates for patching in PMaaS talent and resources, but I'd also suggest that projects at the other end of Loewenstein's thinking might also benefit. Is your in-house talent best deployed on an "easy" project, or would they be better somewhere else in your portfolio? PMaaS can free up existing talent and resources who are working to keep the lights on so that you can allocate them to a place where being passionately curious might have a greater impact.
So, there you go. Something I heard about in the 90s and stored in the back of my mind piqued my curiosity in 2018 and presented a possible secret to success! I'd be passionately curious to hear about any information gaps you have in your project portfolio and even more passionately curious to see how we could help fill them.
Find out more about Project Management as a Service
PS. Looking for an easy holiday read? How about our newly launched E-Book full of Project Management blogs? Download your FREE copy and take it away with you!]]>
It's a psychological habit where you filter your reality until it resembles something more aligned with your existing beliefs. I think we're all a bit guilty of it from time to time.
For example, you think that your co-workers are lazy so all you see is them sloping off for a cigarette, or you believe that someone you work with is not up to the job so all you see are their faults and mistakes, or you think you can't lose weight so you say things like you have a sweet tooth or "diets just don't work for me".
In cases like those above it's fairly harmless, but what about key decisions that affect IT Project outcomes. In these instances, a long-held belief that has become obsolete or turned out to be just wrong could have a really damaging effect. So why do we do it?
I see it as a coping mechanism for all the noise. Think how much information your brain is taking in, from the news on the radio driving into work, the emails and phone calls, the industry journal you read during lunch, the meetings, social media ... blah, blah, blah. Remembering it all and knowing how to process it when the time comes for you to recall all this information isn't easy so you develop shortcuts - like confirmation bias.
Thomas C. Redman, writing for hbr.org observes, "Making good decisions involves hard work. Important decisions are made in the face of great uncertainty, and often under time pressure. The world is a complex place: People and organizations respond to any decision, working together or against one another, in ways that defy comprehension. There are too many factors to consider. There is rarely an abundance of relevant, trusted data that bears directly on the matter at hand. Quite the contrary — there are plenty of partially relevant facts from disparate sources — some of which can be trusted, some not — pointing in different directions."
No wonder we need shortcuts.
I canvassed a handful of IT Project professionals. Just under half denied the existence of confirmation bias.
If you too are dismissive, consider this. Back in the 1960s, Peter Cathcart Wason developed this ingenious method for teaching and testing for confirmation bias. Take a look at the following sequence of numbers ... 2,4,6. What is the secret rule? Ask your colleagues for their thoughts.
By the way, 16,18,20 also fit the rule as do 34,36,38. Got it? Can you suggest others that fit?
If you're thinking 22,24,26 ... 14,16,18 ... 80, 82, 84 ... I'd confirm that these also fit the rule. That confirmation might lead you to conclude that you'd sussed the rule. Until I tell you that 1,2,3 also fit, as do 7, 999, 1002.
The rule is any three numbers in ascending order. It's your confirmation bias that diverts your thinking and leads you to work your way through the two times table. Only when you suggest a sequence that wouldn't fit the rule you envisaged do you get confirmation that you're on the wrong track, but having made your mind up you're never going to suggest 91,92,99 ... are you?
In IT Project Management we have a duty to find that "sequence that wouldn't fit the rule you envisaged"
Indeed, of those I messaged who acknowledged the existence of confirmation bias, some were quick to confess to being repeat victims of it, a few even told me that they had identified it as a problem and taken steps to prevent it.
From all this combined feedback I present ...
Five Steps To Prevent Confirmation Bias Impacting Your IT Project Success
1 - Think Organisational Over Individual
One of my football mad PM friends always says, "You're playing for the name on the front of the shirt, not the back."
Having the values and strategic goals of your business front of mind and aligning your IT Project team with them creates a natural check against confirmation bias. Let's face it, institutional confirmation bias is pretty rare, it tends to be driven by a single, influential individual.
When you approach a project decision with organisational goals influencing your thinking you are less likely to revert to a default bias.
Another of my PM friends calls this the "We think" test. Before he offers a solution, he visualises speaking on behalf of his whole team, all stakeholders, department heads, co-workers and the business mission statement.
Rather than imagining himself declaring, "I think this is the best way forward" he envisages saying, on behalf of everyone, "We think this is the best way forward." Instantly, any potential objections from others spring to mind and allow you to consider whether your decision may be unknowingly biased towards your own pre-existing beliefs.
2 - Resist The Path Of Emotional Least Resistance
In the thick of an IT Project, especially when things are a little "off course", you have to think fast on your feet. It is easy to go with what you know in these circumstances.
The thing is, what worked well in the past (according to your opinion, i.e., what you know) might not be the best course of action now. Challenging yourself out of this comfort zone becomes a habit the more you do it BUT I accept it's hard because what you know is easier than what you don't.
A Farnham Street post 'Confirmation Bias: Why You Should Seek Out Disconfirming Evidence' sums this up quite well, "Our use of this cognitive shortcut is understandable. Evaluating evidence (especially when it is complicated or unclear) requires a great deal of mental energy. Our brains prefer to take shortcuts. This saves the time needed to make decisions, especially when we're under pressure."
Resisting taking the path of emotional least resistance is hard, but rewarding.
3 - Take Independent Advice
One of the most powerful weapons in the battle against confirmation bias is a good old-fashioned independent pair of fresh eyes. If you have a great IT Services or Project Management as a Service partner - use them!
Working in your project, you can become blind to issues and biases that an outsider can spot straight away and the Project Management as a Service market is ever expanding with best-fit solutions for every project challenge.
Confirmation bias in IT Project delivery often means that teams make a decision based on experience and then look for reasons to justify it. This then weights future decisions.
I love the lightbulb moment when a team is stopped in its tracks having been asked ... "Have you considered X, Y, or Z?"
4 - Put Confirmation Bias Checks In Place
When I write an IT Project Management blog, the spark of inspiration for the topic could come from a conversation with a colleague or something that happens working with a client on a Project. Regularly, this comment or observation will become the working title.
I realised, writing my last piece for CIO.com, that when I research further information to flesh out the article, I subconsciously check that I don't just find opinions and views that prove the initial hypothesis of the title or my own beliefs.
For instance, the working title for this blog was "Could Confirmation Bias Be Impacting Your IT Project Success?". It came from working with a team who were stuck in something of a rut - making bad choices and then wasting energy finding reasons to justifying them. But one swallow does not a summer make so I made sure that I canvassed lots of opinions to ascertain whether there was a broader problem.
I've made a commitment to myself to be as diligent with the next big IT Project call I have to make.
5 - Practice Self Awareness
Some Project Leaders just seem to ooze self-awareness. It seems that the more self-aware you are, the more able you are to see the bigger project picture. Mindfulness, of course, is very much in the media these days with celebrities like Emma Watson, Oprah, Jennifer Aniston, Hugh Jackman all speaking publicly about their meditation practices. Less high profile is Tim, an IT Project Manager from London who told me that he meditates twice a day, concentrating on focussing his mind on a single thought (often a project challenge), acknowledging how and when he gets distracted and then re-focusing. He says that this practice is the key to training his mind to stop and recognise biases before proceeding with a decision.
In his mindful.org post ("How to Avoid Confirmation Bias at Work") author of Emotional Intelligence Daniel Goleman writes, "Mindfulness and emotional intelligence can both help. People who have high levels of emotional intelligence demonstrate specific competencies that support taking a broad, unbiased perspective."
I don't think you necessarily need to meditate but becoming more self-aware - being able to step back from yourself and take a helicopter view can help you make subconsciously biased decisions.
Terry Pratchett wrote, "Be careful. People like to be told what they already know. Remember that. They get uncomfortable when you tell them new things ... In short, what people think they want is news, but what they really crave is olds ... Not news but olds, telling people that what they think they already know is true."
In IT Project Management, in an industry moving this fast, we can't be in the business of "olds".
You weren't born with any beliefs. You learn them when you qualify or start working in IT Project Management. If what you learn along the way was wrong or becomes dated then it's imperative that we unlearn those beliefs and learn new ones. I feel like Yoda!
As an industry, we have to prevent confirmation bias impacting successful outcomes.
Find out more about Project Management as a Service
The team was going through one of phases.
You ever have these? Nothing was wrong ... but nothing felt right. They were delivering IT Projects on time but not feeling proud of their achievement. There no high fives or punching of the air in triumph.
No-one could put their finger on the problem.
As the CIO put it, "Decisions felt like wading through mud in wellington boots", success felt more "by luck than by strategy" and it didn't feel like the team was "firing on all cylinders".
This happens occasionally, doesn't it? We are often asked to provide independent analysis of Project Management teams and their procedures, usually, an independent pair of eyes can spot things that have become invisible to you. Plus, you spend all day busy working in your projects, you may not be aware of new innovations from the expanding Project Management as a Service universe. A partner who is up to speed with latest developments, services and solutions from this sector can recommend approaches that you may not even know exist.
We took such a call from this CIO but he had also had an idea that I think is both brilliant and, at first glance, a little "out there".
The next time the team assembled to make a strategic decision, he set up a video camera on a tripod in the corner of the room and he filmed the meeting.
Then, afterwards, he played the meeting back to the team and asked each of the film's stars to take notes and share observations.
The results were fascinating.
1 - For a start ... the meeting didn't start
Not on time at least.
A couple of stragglers moseyed in a couple of minutes late. They literally were JUST a couple of minutes late ... no big deal? Everyone gets held up.
However, as they had walked in holding a freshly made cup of coffee, others felt, the latecomers had made a choice that had made them tardy, i.e., "it's 2 o'clock, the meeting’s starting let's grab a coffee to take in". It was also pointed out that they were serial offenders and that the meetings always started late as a result. Other team members felt that they were being penalised for their own punctuality.
The solution was to agree that meetings would always start on time ... not a second late. Walking into a meeting that is in full flow is embarrassing. The falling quiet of a room, the awkwardness as you find a chair, the tangible annoyance of things being recapped for your benefit ... after you've done that a couple of times you start to rethink your behaviour!
2 - Disproportionate Speaking Roles
As the 'chair' of the meeting, the CIO realised that he talked for a disproportionate amount of time. He genuinely wanted input from his seasoned, experienced team but was self-aware enough to realise he was hogging the proceedings. He held court for about half the allotted time and his courtiers pointed out that they often left meetings not feeling like they had not had their say. They didn't feel engaged or even believe in the decision that had been made.
The solution the CIO came up with was to hand 'chair' responsibility to the project's leader. The CIO then became one of the seasoned, experienced advisors whose input was invaluable to the strategic decision to be made ... just like the others! Everyone had a fair chance to get their view over.
3 - Agenda
Watching the video back, it wasn't clear what the objective of the meeting was. There was an agenda and the invitation sent to attendees’ inboxes had a subject line that told you the issue to be discussed ... but not the clear objective. As a result, the meeting meandered to a 'conclusion' rather than reaching one with focussed intention.
The solution came as a by-product of handing the reins of the meeting to the Project Leader. The CIO was busy, he didn't always have time to really drill down on the specific issues to create clear objectives for the meeting. In this instance, the Project Leader could have produced a more focussed agenda than the CIO - largely because he was living and breathing the issue under discussion on a daily basis. Having clarity on what you're trying to achieve helps you accomplish it.
4 - Non-Verbal And Personal Meeting Habits
After the initial awkwardness that anyone seeing themselves on a TV screen or hearing their recorded voice feels, the team had a laugh with this. One by one they recognised traits in themselves and, in a good-humoured way, in others.
One realised that she was always the 'voice of doom', the devil's advocate who pointed out what could go wrong ... useful insight ... but it meant that this was all she felt she ever did when given a chance to speak.
Another recognised that the pitch, tone and volume of his voice increased as he became more passionate about his point (to the extent that even he couldn't take himself seriously).
There were gestures and facial expressions (one team member's thinking face had been interpreted as anger by his colleagues), body posture, folded arms, eye contact ... all in all lots to take in.
The point was that as the team discussed all of these things it became apparent that they weren't exclusive to this one meeting. Each took away their own personal improvement to make ... my favourite being "I'm going to try to smile when I'm thinking or at least not look as though I'm a bulldog chewing a wasp"
5 - The Meeting Over Ran But Worse ...
The meeting overran by just short of ten minutes, even taking into account the late start and the unclear objectives, a meeting shouldn't vacuum up time from other parts of an attendee's diary. Especially when (and here comes the "But Worse" bit from the header) the last item discussed was when to reconvene ... to finish the meeting. I already alluded to how they had meandered to a 'conclusion' - that conclusion was that they couldn't reach a conclusion!
The self-aware CIO admitted that what usually happens in these instances is that he goes away and makes the decision, reconvenes the team and effectively gets them to agree. So ... what's the point of even having the meeting?
The solution? As well as agreeing to start on time, focussed objectives and agendas and a different chair for meetings, the team is also experimenting with two innovations which seem to be working.
Firstly, shorter meetings. Parkinson's law, that "work expands to fill the time available" is true of meetings. Here allotted meeting times have been cut in half with no negative impact on decision making, in fact, there are signs that it is having a positive effect.
Secondly, stand up meetings. It appears that being on your feet during a meeting creates a sense of urgency and efficiency. There's scientific support for this too, Stanford Business School professor Bob Sutton led a team that compared decisions made by stand-up meetings versus seated meetings. Decisions were taken 34% faster when standing with no difference in quality.
So there you go.
If you're going through a phase where either nothing feels right or (worse still) nothing IS right. Set up a video camera and watch yourselves back.
And if that still fees a little bit "out there", get an independent pair of eyes to take a look and what you do, how you do it and how you could do it better.
And ... CUT! That's a wrap.
Find out more about Project Management as a Service
It's a webcomic called "xkcd" by Randall Munroe, an American cartoonist, author, engineer, scientific theorist, and the creator of the most addictive website ever! Especially the site's "What If" column, where Randall attempts to scientifically answer outlandish, hypothetical questions sent to him by readers.
Questions like 'what if what if you tried to hit a baseball pitched at 90 percent of the speed of light?' It turns out that not only would it be hard to hit a home run but as air molecules would not have time to escape the trajectory of the ball, the resulting thermonuclear explosion would take out half the city. Randall explained more on this in his 2014 TED talk.
"What If" got me thinking ... if it's possible to work out what would happen if all the rain from a thunderstorm fell as one huge drop then surely it's possible to predict the consequences of events within the life cycle of an IT Project.
Indeed, when an IT Project fails or hits a significant challenge (one hat impacts delivery or budget), there is usually a post-mortem logical explanation. Late delivery, for instance, could be traced back to scope creep ... you can usually identify the exact stakeholder request that caused the project's timeframe to buckle.
Surely, something that is so obvious and logical in a post-mortem could be predicted or identified in a pre-mortem ... Couldn't it? Hindsight is a wonderful thing but 'what if' you could develop foresight?
As far back as the 1980s, researchers found that through 'prospective hindsight' you increase your capability to forecast the reasons for outcomes in the future - by imagining that an event has occurred and all its consequences. In their 1989 work "Back to the future: Temporal perspective in the explanation of events" Deborah J. Mitchell, Jay Russo and Nancy Pennington suggested that this could be by as much as by 30%! It seems there could be a lot of potential in managing those IT Project "What Ifs".
In the September 2007 issue of Harvard Business Review, Gary Klein writes, "A pre-mortem in a business setting comes at the beginning of a project, rather than the end, so that the project can be improved rather than autopsied. Unlike a typical critiquing session, in which project team members are asked what might go wrong, the pre-mortem operates on the assumption that the “patient” has died, and so asks what did go wrong. The team members’ task is to generate plausible reasons for the project’s failure."
Astro Teller, captain of Google's moon-shot factory X, spoke passionately about the concept of pre-mortems in a talk he gave for Stanford's Entrepreneurial Thought Leaders series in 2016. At X, teams imagine (in some considerable detail) that a project has launched and predict what could go wrong. Then, depending on the likelihood and seriousness of the problem, which is judged through a mechanism whereby the team votes up or down the highlighted issues, the organisation can be proactive and take steps to stop the hypothesized events from happening.
I've seen these "pre-mortems" work spectacularly well. Your team is assembled and told to visualise that the project (upon which they are about to embark in real life) has failed. They are then tasked with listing all the reasons why they personally and independently believe this would have happened ... especially those things that they wouldn't usually flag (because of workplace politics or for fear of stepping on someone else's toes). Often, within these predictions of doom, lie some nuggets of insight. Insight that can forewarn you of potential challenges and banana skins. A great example of this was a team who identified that a potential reason for failure could be that their competitor launched a similar product. They imagined their response, they became more innovative and as a result are about to launch a far superior product than the one that they had been planning.
Other IT Project teams have mitigated against future potential failure by developing a relationship with a Project Management as a Service partner. They future-proof their projects because, whatever happens, a seemingly bespoke and ready-made patch is available on demand. The secret here is that, although you may never have encountered the challenge that is threatening to sink your project, somewhere else on the planet ... someone else will. They will also probably have found a solution that you can use. A great PMaaS partner is best placed to access the market and find that solution giving you the ability to meet head on whatever is in your future. If it turns out that your problem is truly unique then the PMaaS sector has some of the most innovative and flexibly minded talent available ... I'm yet to find a problem to which there isn't a PMaaS solution!
'Prospective hindsight', the pre-mortem or managing IT Project "What Ifs" sounds like such a good idea ... it makes you wonder why more project teams don't invest time and energy in this area.
Research psychologist Gary Klein suggests "many people are reluctant to speak up about their reservations during the all-important planning phase. By making it safe for dissenters who are knowledgeable about the undertaking and worried about its weaknesses to speak up, you can improve a project’s chances of success."
X's Astro Teller talks about creating a culture where individuals feel safe to raise a hand and flag potential issues. He says, "If you get thrown under the bus ... (if) people go after you about it. If our culture isn’t one that rewards you for doing that, that’s the last time you’re gonna do that ... the hard part is relentlessly and repeatedly chasing down those moments where it’s not working. He needs a hug if he said something brave. I mean a physical hug, an actual hug or a high-five or whatever. Then if he actually gets a hard time from someone for having written that down, what are we all gonna do to defend him."
Few businesses have that culture. I know of one company that actually boasts about this in their mission statement, it's literally painted on walls throughout the building and the subject of a screen saver on every PC. However, the number of people who have "left the business" soon after flagging up a potential failing has created a culture where those remaining stay silent and safely below the radar (especially if it's a potential management failing they're flagging). A far cry from Astro Teller's hug!
Another reason that teams don't do it is that there's never a good control experiment. You could identify a potential problem, mitigate against it happening and when that failure doesn’t happen you don't know for sure whether it might have just never happened in the first place. It's kind of like a plot from Doctor Who or Back To The Future!
What I will say is that the team I referred to earlier could have easily countered their concerns about "What if a competitor launches a similar product" with the question "... yeah, but what if they don't?"
Actually, in this case, they'd have been right. Their rivals are way behind and nowhere near launching a similar product. They could have rested on their laurels and brought the original product to market ... it would have been OK. However, asking their 'what if' question made them raise their game. The difference is that the original product would have satisfied the market but the more innovative one (borne out of the 'what if' thought process) will disrupt it.
So, in conclusion, great culture and great relationships may be the cornerstones of how to predict the unpredictable. Try asking "what if" and let me know if you start to see around a few more corners. If you then need some inspiration to help deal what's round those corners ... what if ... you give me a call?
Find out more about Project Management as a Service
hbr.org - Performing-a-project-premortem
I walked into a Project Management Office recently, and on the wall, in large letters above the Project Leader's desk was the phrase 'No "Ifs", "Buts" Or "Maybes"'.
At first, it looked like one of those platitudes that you often see, sharing wall space with "Be The Change You Want To See" and "Teamwork Makes The Dream Work" (apologies if you have those on your wall). I asked the team leader, Malcolm, about the poster and he told me it was his own creation, to remind him of his personal philosophy about the use of language and the impact that it can have on IT Project outcomes.
He explained briefly how he believed that "if", "but" and "maybe" were words that could cast a negative shadow on Project Management thinking. I thought about what he said on the drive home and wished we'd had more time together.
When I got home an email was waiting for me that went into more detail, so I thought I'd share it with you and perhaps start a conversation about what other words, phrases and hard-wired beliefs we should banish from our collective Project Management vocabulary.
Here's what Malcolm wrote about "if", "but" and "maybe"
"If" introduces a conditional clause ... 'if the sun shines we can have a picnic'. There's no place in our Project Management thinking for presupposed conditions that dictate outcomes. If it rains, then we'll have our picnic indoors or on a rug in the garage. Too many IT Projects fail because of dysfunctional conditions ... my epiphany came years ago when a project leader used to say things like "if the scope creeps anymore we're in fatal trouble", "if delivery is delayed there will be penalties", "if we exceed our budget for outsourced services, we’ll have to cut back on overtime". In each of these cases, we'd either rein in scope creep or ensure that impact on delivery or budget was clearly communicated and agreed, explain why delivery was delayed and renegotiate a new date or make the case for more budget for overtime ... rarely were any of the "ifs" fatal.
"But" opens the door for excuses. 'I'd love to go on that picnic but it's raining'. In IT Project Management "but" can kill innovation. Again, I had a eureka moment when I heard a CIO once say "It would be great to be able to have an extra Project Manager for a few days but the budget won't stretch". I did the maths and the penalties saved by meeting KPIs on a huge project alone would have justified the 'expense'. This project was also devouring resources from across the portfolio, making them late, so extra skilled talent would have had a massive positive impact ... BUT apparently, it was too expensive.
David’s note: Actually, hiring in talent through the Project Management as a Service (PMaaS) can often be done without net increase in portfolio/project expenditure.
"Maybe". The most indecisive Project Manager I ever worked with used the word 'maybe' A LOT! With the benefit of hindsight, he was putting off making a decision until he really had to. I recall one afternoon, in the early days of phone apps, we had an app that just wasn't ready for launch ... it had a few bugs ... needed baking a little longer! We asked if we should delay, should we get the project sponsor to make the call, the PM answered 'maybe'. All the maybes added up until the time to make the call had passed – it really came back to bite us!
Google the word "maybe" and among the searches that comes back is a graph that shows usage of the word from 1800 to 2008. We are in the grip of a 'maybe' epidemic that has been rising since the 1970s! What does maybe mean? It means you're not certain, you're unsure ... we have no room for "maybe"!
Interesting isn't it?
By the way, I love Bernie Roth's approach to the word “but". In his book “The Achievement Habit”, the Academic director of Stanford's famous 'd.school' suggests that you say "AND" instead of “BUT”. He writes, “When you use the word 'but', you create a conflict (and sometimes a reason) for yourself that does not really exist.”
In other words, to use the example quoted by Malcolm, it would be great to have an extra Project Manager for a few days — AND the budget won't stretch. Using AND instead of BUT you acknowledge that the need and the budget concerns both exist, and this allows you to find a solution that meets both clauses. You could ask for extra budget, actually get some quotes, look to save elsewhere. BUT, on the other hand, kills the idea of hiring that extra pair of Project Management hands.
When you use the word AND, “your brain gets to consider how it can deal with both parts of the sentence,” Roth writes.
I'd love to hear from you - what other words could vanish from OUR lexicon and not be missed?
Personally, I always mentally rebuke myself whenever I present an alternative solution as "the other way" ... rather than "another way". As if my idea were the only other possible fix - the arrogance of it!
Which word or phrase would you like to see the back of in IT Project Management?
Find out more about Project Management as a Service
Failure Is the new success. Here are five ways that you can embrace failure and enjoy its unexpected benefits.
Knowing when to say enough is enough and kill an IT Project must be among the hardest skills to learn. I'm not sure any of us ever totally master it either. When your sponsor has invested a considerable amount of money and you and your team have invested time, blood, sweat and tears it can be difficult to admit that a successful outcome may elude you.
It's has been front of my mind of late because I've had to deliver this news to a couple of clients who had asked my advice on their off-course IT projects.
One, in particular, demonstrated how painful this realisation could be. The CIO asked me to look at what he described as a "runaway train" and when I arrived the team was diligently running through the failing project solution checklist ... "What if we asked for more money, more time, more resources, more people, what and who could we borrow from other projects in the portfolio ...?"
If you think about an actual "runaway train" what would you do? Add more fuel? Borrow drivers from other trains? Add more engines or carriages? Or would you look for a way to stop it before it did some real damage?
You need to give your IT teams the freedom to fail.
This team of consummate project professionals were, naturally, so into their own project that they were willing to sacrifice the efficiency of others in the portfolio to deliver. Of course, if your project is the most strategically important mission on the books and will deliver business goals that are key to your company then this is a good option but this wasn't the case here. The project had one of those arbitrary deadlines that you apply because “a goal without a deadline is just a dream”, the team had glaring capability gaps and, frankly, a much better (and cheaper) solution to the business need existed in the Project Management as a Service Market.
They told me that they felt afraid to kill the project because "failure was not something that was culturally acceptable".
Let's think about that for a moment. If you stopped that real "runaway train" you would be a hero, you would probably get an award and a fabulous write up in the newspapers. Why don't we do this with IT Projects? Why don't we incentivise putting up your hand and flagging a fatal flaw?
Have you ever seen Astro Teller's TED talk "The unexpected benefit of celebrating failure"? It's brilliant! As head of X (formerly Google X) Teller talks about how 'failure' is rewarded. He says, "We work hard ... to make it safe to fail. Teams kill their ideas as soon as the evidence is on the table because they're rewarded for it. They get applause from their peers. Hugs and high fives from their manager, me in particular. They get promoted for it. We have bonused every single person on teams that ended their projects, from teams as small as two to teams of more than 30."
I encourage you to watch the whole TED talk, it's really interesting and inspiring. Teller shares how they consistently try to break their projects and find the ‘fatal’ flaw that will kill off an idea, he adds, "Trying to prove that we're wrong. That's it, that's the secret. Run at all the hardest parts of the problem first."
Teller says that they actually get excited and cheer, "Hey! How are we going to kill our project today?"
Now, you could argue that if you have an under-resourced project you don't have the luxury of being able to do this - but what a culture! If you started every project with an attitude like this you may actually find that your projects fail less and that you get recognition (and not criticism) from your sponsors when you have to make the ultimate call.
When I pointed out the cheaper PMaaS alternative to the board of this client I was thanked, patted on the back and paid for delivering the news that the people on the team had been afraid to. You must give your teams the same kind of freedom that you would allow an external, independent pair of eyes like mine. I came at the project with no baggage, no parameters and no stakeholder expectations - just an instruction to deal with the runaway project. If that means killing it then you need to afford that freedom of judgement to your talent.
The thing is, in an IT Project, hitting the brakes is sometimes the best thing that you can do.
Furthermore, uncovering a huge flaw in an IT project doesn't always mean that it's the end of the project. Often it can actually just re-route you to a more productive path that delivers the outcome you need - or sometimes an even better one. As Teller puts it, "Enthusiastic scepticism is not the enemy of boundless optimism ... It unlocks the potential in every idea".
So what causes project teams to doubt their judgement when they find a potentially project killing problem?
In his book, ‘Originals: How Non-Conformists Move the World’, organisational Psychologist Adam Grant suggests that there are two types of doubt... "self-doubt" and "idea doubt".
Self-doubt ("I can't do this") is debilitating, isn't it? You're frozen to the spot, you don't act. You don't speak up or flag when something is wrong because you are afraid of the consequences ... like feeling embarrassed. This is the kind of doubt that leads project teams to sit on or cover up flaws that they find. It's not healthy.
"Idea doubt" on the other hand is exciting and motivational. When you have "idea doubt" you challenge the status quo. You push boundaries, think outside your comfort zone, you test yourself and your peers and you hone your 'act' until it is perfect.
Grant has an interesting way of illustrating this with the web browser that you use. He claims that there is evidence that users of Firefox and Chrome outperform users of Internet Explorer or Safari.
It's not because one is particularly faster than any of the others nor, actually, is it for any other technical reason. It's how you come to be using them. Users of Safari or IE (or Edge these days) are using the default browser that came with their device. Users of the Chrome and Firefox, conversely, challenged the status quo, they looked for and downloaded an alternative that suited their needs better.
It's an interesting hypothesis. When I did I did a straw poll of project management talent in my phone book it seems to have some solid foundation. Friends and colleagues I would expect to challenge the value of continuing a dying project all say they use a browser that was not preinstalled on their PCs, tablets and phones.
Food for thought.
Surely, for IT Projects to thrive we need to populate our teams with these types of individuals. It's not just about prescribing what browser your talent uses, a bad project doesn't become a good one when you download Firefox! It's about having the type of talent who challenges the default setting and looks for better solutions ... without fear of things not working out.
Here are five ways that you can embrace failure and enjoy its unexpected benefits.
1 - Get Another Pair of Eyes
Often, in the thick of an IT Project, you can't see beyond the next task. Of course, it should be someone on the team's responsibility to have a broader perspective, a helicopter view. Even then though, when you've poured your soul into a project it can be hard to spot warning signs, harder still to be the one who says it's time to pull the plug.
I am sometimes called in to do this and because a third party independent view is less coloured by a project's history. I can give a black and white assessment. One client said that it was like taking a beloved family pet to the vet when you know what the kindest thing to do is ... but you need someone else to make the judgement call.
2 - Encourage Flaw Flagging
Too many projects fail because flaws are not flagged. Usually, it is because there is a culture that does not encourage it.
Let's be clear a fatal flaw will kill a project whether it's flagged or not, flagging just brings project termination forward ... saving precious time, money and resources that can be deployed elsewhere more effectively.
More commonly though flaws are not fatal. Flagging means they can be assessed and acted upon.
3 - To Kill Isn't to Fail
We do need to take a leaf out of X's Astro Teller's book. As painful as killing a project is, it is only a failure if lessons are not learned from it. Watch Teller's Ted talk to hear how Google's "moonshot factory" celebrates 'failure' and you will instantly feel differently.
How many vacuum cleaners got binned before James Dyson perfected his first bagless machine? Thomas Edison created a terrifying talking doll that gave people nightmares before he invented the lightbulb (at something like the thousandth attempt!), R.H. Macy (of Macy's department stores) had a series of failed retail ventures throughout his early career.
All of these people killed projects that weren't serving them. Are they failures?
4 - Believe in Boxless
The team behind the "runaway project" that I mentioned earlier had a philosophy of "Out Of Box Thinking" that usually served them well.
What box though? I understand the sentiment behind this piece of management speak but when you open up a project to the infinite solutions that exist you create more possibilities, including calling it a day!
The "runaway project" had a great relationship with a Project Management as a Service partner. Often, when they needed extra resources or people, they drafted them in through this partnership. It was such a regular, ongoing relationship that it had fallen within the 'box' so when they ‘thought out of the box' the PMaaS partner was not one of the options considered.
It would be like, a Firefox user from Adam Grant's hypothesis never using Safari just because it's a default browser.
Don't think out of the box, think as if there is no box!
5 - Have Lots of Options. Lots
The artist Prince had just 15 UK top ten singles during his life. Fifteen!
When he died it emerged that there was a cache of unreleased music that was so vast that a posthumous album could be released every year for the next century.
Prince was a musical genius! To create those fifteen top ten hits he produced 100 years of music that he didn't consider good enough for release. Sound engineer David Rivkin said that he and Prince would create two songs a day - were all of these failures? Or were they necessary experiments that ultimately led Prince to hits like "Purple Rain".
Prince ... Astro Teller ... James Dyson ... Thomas Edison ... they all have something in common. On the road to success, they are not afraid to fail.
AND it is with words from Thomas Edison that I leave you. "I have not failed 10,000 times — I’ve successfully found 10,000 ways that will not work."
Find out more about Project Management as a Service from Stoneseed
TED.com - Astro Teller
Daily Mail - What browser