I’ve just watched a news article about the brokering of trade deals, what they are, why countries need them, the benefits of them and how difficult life can be without them. It got me thinking.
What they were describing, on a geopolitical level, shared so many characteristics with a struggling IT Project that I’d been asked to cast a casual eye over.
The Project team is a mixed group. Twenty-somethings with their freshly minted Project Management qualifications working side by side with more, er, shall we say more seasoned, more mature practitioners (who have years of experience). The biggest issue is that the individuals in the project team don’t have a lot in common, largely because of their age gaps, backgrounds and experiences!
In fact, the individual members of the team are like separate countries on a continent. Each has their own agenda; each has their own “way”; each has their own proud history. You can see why the news report on trade deals resonated.
Added to the mix, the project team is a prolific user of Project Management as a Service resources. Whenever they have a resource issue, I get a call and hook them up with brilliant talent from the PMaaS universe who can parachute in and ‘save the day’. This adds an extra variable that can skew the team older or younger, etc, at any given time.
Trade Deals Within IT Project Teams
Each of us working on an IT Project has a CV, it’s how we got the gig! Each entry on those CVs is a unique data point that can be mined for the benefit of everyone on your team, not just your current team but every team you will ever work on.
Think of the exponential knowledge bank that is literally sitting in the room with you when you work on an IT project. How many people on your team? Multiply that by how many projects they have worked on. Then, multiply that by the number of people that would have been on each of these projects, and this new number by all of the projects on their CVs. Imagine that each point is like an entry in an IT Project Management encyclopaedia. It’s like that legend about the grains of rice and the chessboard where the guy asks the emperor for a grain of rice on the first square, doubled on each square thereafter.
Why wouldn’t you want to enter into a “quid pro quo” trade deal with everyone you meet with access to this kind of knowledge bank?!
Let’s consider the project that I’d asked to take a casual look at. Take two of the team members, I’ve changed some of the details to respect privacy but imagine these two:
Brandon is 29. He has a few years of experience under his belt. IT, project management and this particular team are all he’s ever known. A resume of his last 15 years would read: computer club leader at secondary school; tech degree at university; gained project management qualifications; landed project management job with current employer.
Jennifer is 49. She has many years of experience under her belt! She has just returned full time to the industry after raising her two boys. The company she started her project management career with is long gone, as is the one she was working at when she left to start her family! She has seen many changes! She maintained a part-time presence through what she calls her ‘priority parenting’ years, benefitting from the flexibility of Project Management as a Service opportunities to keep her hand in.
You can see how differently these two will see their jobs, roles and careers. Even down to getting the whole team together for a social night out is tricky – Jennifer loves a sit-down meal and nice wine with a taxi home at 9, Brandon prefers the pub, followed by a club and an Uber home for a few hours of sleep before work later the same morning!!
Getting such diverse team members to interact and bring their complementary skills to their projects is the key to turning around this struggling team. I think that “trade deals” is the way to do this.
Brandon is great at cutting edge tech, trying new methods and project software, Jennifer prefers to use her tried and tested software (she is, by the way, a spreadsheet genius!)
Brandon can be a little abrasive, he ‘rubs’ people up the wrong way – often without realising. Jennifer has EQ in abundance and years of experience have taught her that diplomacy in negotiation is usually more effective than stamping your feet.
The tendency so far has been to split the team into likeminded sub-teams for completion of project tasks, so the young, abrasive, go-getters head in one direction and the more mature, experienced go in the other. I’ve suggested that they work together more.
This is where the “trade deal” comes into it.
Put the Brandons and the Jennifers on the same team and, alongside the obvious completion of tasks, there should be a direct instruction that they learn from each other. A “trade deal” – mutual mentorship!
In two future blogs, I’d like to drill down on the Brandon and Jennifer dynamic. Airbnb’s Chip Conley’s thought leadership on the concept of ‘modern elders’ has much to teach more experienced project team members and leaders blessed with this resource on their team. I also think that there is a lot that can be done to allow more junior members of the team be heard. So watch out for those blogs!
“Mutual mentorship is the future.”
Perhaps the most famous evangelist of “Mutual mentorship” across generations is Airbnb’s, Chip Conley. His Tedtalk and his lecture for ‘Entrepreneurial Thought Leaders’ (Stanford’s Speaker Series) are inspirational insights into this way of thinking. Conley had been hired to help mentor Airbnb cofounder Brian Chesky, but quickly discovered that he had a lot to learn himself. He is the first to admit that he wasn’t the most tech-savvy new hire when he was headhunted by Airbnb at 52 years old, he didn’t even know what Uber was! However, he set out to see if his “wise eyes” could learn something from his new colleagues’ “fresh eyes.”
What he discovered was that sharing knowledge, combining his many years of experience in the hotel and hospitality industry, and his leadership skills, with his new colleagues’ digital expertise and fluency, would benefit the company as a whole.
“Opening a pipeline of organizational wisdom is the trade agreement of our times,” he once said. “That’s the new sharing economy—sharing wisdom across generations.”
“Mutual mentorship is the future.”
The Biggest Missed Mutual Mentorship Opportunity
In IT Project Management there is another mutual mentorship opportunity that is often overlooked. We sort of touched on it earlier – it’s PMaaS.
When you use Project Management as a Service resources you are adding fresh eyes, different perspectives and a whole back catalogue of unique experiences to your team. Why wouldn’t you see this as a great learning opportunity? Sadly, few do!
What happens in most organisations is this: the PMaaS talent arrives; they do the job they were hired for; they leave.
All that extra experience departs untapped with the talent. What an opportunity missed!
What happens in GREAT organisations is this: the PMaaS talent arrives; they do the job they were hired for; AND all the while in-house talent becomes a knowledge sponge for new ideas, different approaches, fresh ways of thinking.
It’s interesting to note that the PMaaS talent themselves are more than likely always doing this. It’s part of their DNA to be inquisitive about alternative methods because adding them to their skillset increases their value. When you hire PMaaS resources it is worth remembering that you are not just hiring in a pair of hands to help deliver a project, you are buying the accumulated knowledge of everywhere they have EVER worked.
Again, why would you not want to learn from this!
In conclusion, we have never had such great access to knowledge about IT Project Management, the internet is teeming with it! But Project Management remains an inherently human pursuit, it’s the fingerprints on a project that bring it to life way more than the code! The most fulfilling way to learn is to share, to interact and, yes, to steal great ideas from each other!
So, look around your office, think about the members of your project team, observe the temporary guy contracted in from your Project Management as a Service partner. What great insight are you going to pinch from them today?
Burnout and Boredom.
Great IT Project talent doesn't suddenly start performing less well for no reason. IT Project rock stars don't lose their A-game overnight, they leave clues. Project managers often relinquish this responsibility as ‘a problem for the line manager’ but as leaders, we are just as responsible. Shaking things up – breathing life into a bored or burnt out project team is a fabulous investment in time and will pay back in greater productivity and project success.
Burnout and boredom are on the rise. They are symptoms of a perfect storm of increasingly complex IT Projects, tighter budgets, greater transparency, blurred business needs, stakeholder interference, actually it's a long list and it's stressing me out just writing about it so let's cut to the cure.
IT'S ALL ABOUT YOU
The first thing is to accept responsibility. As Project Leader, it's all down to you! Yep! All of it!! The project manager who is having the extended cigarette breaks, the guy who seems to spend twice as long as everyone else boiling a kettle, the BA who quickly flicks their screen from Facebook to Slack when you enter the office – all the above and more.
In the same way that you'll take the applause from the c-suite when your project delivers in triumph, you need to also shoulder some responsibility for your team's less productive behaviours and address them. BUT find out what’s driving them first!
Does YOUR team understand the purpose they work toward? I can't think of an IT Project that has ever failed where the team is 100% on board with the mission vision. It just doesn't happen! On the contrary, teams who are bought into the WHY of an IT Project delight in finding the HOW. Make sure that your project’s vision and its importance to the business is understood by everyone.
Complexity is one of the greatest drivers of both burnout and boredom. IT Projects are getting increasingly complex and I'm seeing a lot of frazzled talent trying to keep up with it all and a lot of apathy among those that have given up trying.
Better training; extra resourcing from the Project Management as a Service market; better separation of tasks into more manageable, workable chunks; more open cultures where talent can admit they're out of their depth and not be judged ... there's a seemingly endless list of things that you can do to help with complexity.
Another great cause for fatigue and ennui is overexposure to stakeholders and contacts within the wider business. I covered this in a recent blog about corridor conversations becoming business expectations, in our desire to be more transparent we have left ourselves open to 'important' requests coming from all angles. Distractions, like a member of your team being asked for a status update, can take a few minutes to accommodate but they soon add up.
Also, this can be the thin end of the wedge, - if you're not careful. A friend is a project manager who has a c-level stakeholder who frequently asks for status updates as an 'ice breaker' ahead of then asking for a more time-consuming piece of work. "How's project X coming along?" he'll ask. The unsuspecting team member will break off to give him an update at which point the exec will say, "While I've got you, could you just ..."
Disciplined schedules and routine are key to productivity and contentment, project teams soon get worn down by constant interruptions to their workflow. Setting up clear procedures for how the business interacts with your team will make a huge difference. The PM above, for instance, has just instigated an "everything through me" policy to protect her team.
IT AIN'T WHAT YOU DO, IT'S THE WAY THAT YOU DO IT
Consider YOUR impact and how your expressions may affect your team. This is a hard one and needs a bit of honest self-awareness.
One of my friends had an epiphany recently, morale was low and it turned out her facial expressions were not helping! She found this out when she overheard team members talking about her "face of thunder"!! She was actually in good spirits but her look of concentration was being misread as moody, worried or furious by her team. It was infectious. She told me that she was mortified - she is the least moody, worried or furious project leader I know - but her resting face fell naturally into a frown! She said she has started smiling more and the mood has lifted.
Think about how you interact with your team, the words you use, your tone of voice, even the look on your face - it could be affecting productivity.
HOUSE OF FUN OR HOUSE OF PAIN?
The IT Projects you work on disrupt markets, drive innovation, stimulate growth, secure jobs, etc. What we do is a serious business. But it doesn't have to not be fun. In fact, it should be fun and as IT Project leader you are responsible for making it so. Not in a David Brent way, I mean, this isn't going out for drinks, declaring fancy dress Fridays and hosting baking competitions - although, if these work for you .. go for it!
No, this just ensuring that coming to work is a pleasure, not a chore.
And you can do this with the smallest of tricks, one Project Manager I know incorporates song titles into his emails and project reports - the team actually looks forward to receiving them and spotting the songs! I've borrowed this for this blog, did you notice?
As IT Project Leaders, together with delivering a healthy return on investment, measurable business value and stakeholder needs, increasingly we have an extra responsibility - to safeguard the wellbeing of our talent. It really matters because without your talent you don't have a hope of delivering those other things expected of you! While that is a great reason to have their back, it should be about much more than this.
It's a human thing, IT Projects are increasingly complex, virtual teams and remote working mean less contact - that small human touch is a leadership skill all IT Projects will benefit from.
In this, the first of a short series, I'm going to look at some of the issues that you and I face and share some solutions. If nothing, else let's acknowledge that the challenges are universal and take solace from the fact that it's not just YOU!
The inspiration for this series came from a conversation with a CIO friend this week, I'm paraphrasing here but he said that IT Project Management for business is "like running a restaurant, the restaurant is full, every table is taken so we're also building an extension to increase capacity. All the customers are ordering à la carte. We're revising the menu constantly and upgrading the kitchen so that we can deliver better. Meanwhile, all the customers are asking why we're not serving at as fast as a McDonalds."
It is a high-pressure environment. Business needs innovation. I.T. is no longer a back office support function, I.T. is now a front and centre driver of business change and growth. This is GREAT and it comes at a cost.
The CIO I was talking with above has a busy IT Project portfolio, it is "scheduled to within an inch of its life" and although there is capacity for 'the unexpected', these margins for manoeuvre are slender. The wider business does not always see this and quite often members of his team are being approached by senior business managers with something that is "needed yesterday".
On a number of occasions, questions asked in passing in the corridor, at the water cooler or even in the bathroom (!), have become business expectations that the exec asking has requested a status update on a few weeks later.
The toilet one is actually the best example. The CEO asked a project manager a "would this be possible" type of question - in the gents!!! Like you do! The project manager said that the thing would be possible and both men went away with different perceptions of the conversation: The Project Manager thinking that he'd answered a question about what could be achieved; the CEO thinking he had set in motion the start of a project to achieve it! When the CEO asked the CIO for a progress report at a board meeting a month later the latter didn't have a clue what he was talking about!
This happens a lot, I mean not usually in the lavatories, but many IT Project teams talk of business "priorities" overwhelming schedules from out of nowhere. So, what can you do about it? Here are five thoughts:
1 - Have a procedure (And share the procedure with everyone)
One project team I work with have what they call the "smoking break rule". In short, if the request can be satisfied in the time it would take to pop outside for a cigarette then they just go ahead and do it. After all, team members do this across the day, and it doesn't affect overall productivity and outcomes. So, things like ad hoc status updates, help with a project that has been delivered into service, an enquiry about whether it would be possible to do something, this kind of thing falls into this category.
Anything that might take longer or that could disrupt the schedule must be requested in a more formal manner, so the CEO's perception of that bathroom conversation would land on this side.
Slowly, business units are wising up to the fact that they can't just ask IT for something without it having an impact elsewhere.
2 - Communicate
Following on from the last point, we could probably all work on our communication when it comes to 'left field' requests. It's just a bit awkward, isn't it! Especially if it's the CEO in the bathroom!
There isn't a single IT project team I work with who likes to say 'no' but, with a healthy reframe, many have learned how to. I always think, by saying 'yes' to a request that comes from "out of the blue", what will you say no to that's "in black and white"? In other words, what might by agreeing to an undocumented request today, jeopardise on your schedule that is due for delivery in the future. Everything on that schedule is business case filtered - IT Projects don't get a green light without clear ROI (return on investment). The new request should at least have the same level of scrutiny.
One Project Leader has a great way of dealing with extra requests. No matter how senior the asker is, he takes them to his whiteboard and shows them his team’s workload. He highlights the projects that would have to be delayed to accommodate the request and asks the exec to make the call about what to put back. Amazingly, almost all decline and agree to put in their request through the proper channels.
3 - Collaboration (think beyond YOUR team)
Think of the Project Management Services Universe as a huge catalogue from which you can now buy a solution to just about any challenge and you instantly start to feel the pressure reduce. It really is that simple. Project Management as a Service (PMaaS) can now provide everything from end to end Project Management Office to individual team members to fill a capability gap.
I.T. is now the centre of most business operations and it is a position that comes with some responsibility. Rather than saying 'no' to requests it is worth considering external solutions. I know of at least two IT project teams who have delivered market disrupting outcomes that would have been way beyond their capacity had they tried to accommodate them in house. They sourced quotations for end to end project management services to present to the board, which were accepted and ran alongside their existing portfolio.
No-one in the wider business knows (or cares) about any of these arrangements and just thinks that the IT department are "amazing" for delivering such great work. Who wouldn't want that kind of adulation?
4 - Honesty around capacity
IT used to try to keep capacity challenges a secret. We didn't want to appear vulnerable. We were like the Wizard of Oz hiding behind a curtain! We didn't want to shout that we were lacking because this would somehow reflect badly on us as a department and our ability to plan. This needs a reframe. When the Transport Director doesn't have enough vans, he doesn't start loading up his BMW, he calls the van rental firm.
I don't know why IT feels insecure about doing this but it IS a story that I see repeated time and again. Maybe, it's because of the metrics by which we are judged. We are a results-based sector and have probably become eager to please because that's how we get our bonus or the green light on that next project. If there were rewards for the creativity with which we manager capacity we'd ALL be millionaires.
We need to be more transparent about our capacity challenges. Our capacity delivers business change and growth - limit that capacity and you limit your firm's potential in these areas.
AND Something really exciting happens when you're transparent about capacity. Other parts of the business become advocates for IT!
If your sales department needs a new Customer Relationship Management (CRM) system to manage and close deals more quickly and you're honest about your capacity to deliver, what do you think the Sales Director does? At the next board meeting she is saying, "Hey, IT needs this person or this extra resource!"
The business will still love you after you admit gaps!
5 - Educate
Many other business units don't understand what we do, not really. I mean they know when the network is down or when the Wi-Fi isn't working but what we do the rest of the time isn't on their radar. They see the component of what we do that impacts them but not the overall complexity. As Blackadder once said, explaining the “The Ravelling Nancy” cotton ‘raveller’ to the Prince Regent, "I am one of these people who are quite happy to wear cotton but have no idea how it works." Most in HR, Sales, Distribution, etc are similarly happy to use their H.R., Sales and Distribution software blissfully unaware of how it works.
If we're being honest, we've used this to our advantage - there is safety in anonymity! These days though this comes at a cost. Perception is powerful and although IT Project teams always look busy it is only when we deliver a project every six months that this is really noticed by the wider business - whereas everyone sees the fruits of the other departments, the new hire, the orders flying in, the vans trucking out – on a regular basis.
This is why the perception exists that you can ask someone from the IT Project team a question on a Monday and have it delivered by the Friday.
My CIO friend Kev sends out a weekly bulletin email, another has a HUGE whiteboard visible from the corridor showing tasks completed and their business impact - you will find your own way but it is time to educate your business colleagues about just how busy you are on their behalf!
In conclusion, I'm not sure that there was ever a time when undocumented requests were an acceptable way to get IT Projects initiated but now, more than ever, the complexity of the projects does not allow much room for those "can you just", "when you have a minute" requests.
I've just shared five, there are infinite ways we can address this but it's a conversation that we need to start having. Right after we've all agreed that the toilets is no place to conduct business.
How does the word “Conflict” make YOU feel?
I asked a few colleagues and their responses ranged from anxiety to aggression, from some there was shortness of breath and from others a 'bring it on' deep inhalation.
"No-one likes conflict," said one.
On the contrary, I LOVE it! Here's why.
My friend Gav told me about an IT Project he'd been working on that had been plain sailing throughout, there was a great spirit among the team and the project had delivered on time. Sadly, it was over budget.
In the debrief, a team member had said something that was really interesting about a key part of the project had been taking up a lot of the team's time. They were scratch building an exciting app that would disrupt the market and deliver real business value, but they had been chasing bugs that had really pushed up costs.
Gav asked his team what they could have done better, and one guy mentioned that he'd found the solution they were scratch building as an off the shelf product but hadn't mentioned anything at the time. Why? He didn't want to upset his colleagues who were very proud of the work that they were pouring their hearts and souls into.
He's right, it would have caused conflict, but the outcome of the conflict is that it could have brought the project home under budget.
I love conflicts because they flag up challenges like nothing else and usually lead to much better outcomes. They are also just GREAT for clearing the air and establishing your reputation as an in control, all-rounder.
All too often conflicts lead to predictable responses, like fight or flight or sweeping issues under the carpet. Here are SEVEN ways to ensure that conflicts really ARE your greatest project opportunity.
1 - Listen - really listen
Rockefeller, one the planet’s most successful businessmen used to say, "Success comes from keeping the eyes open and the mouth closed."
It's the same with conflicts in IT Projects. When you TRULY listen to what your team is telling you, you deep dive into the challenges that are holding your project back.
2 - Acknowledge the feelings
Many IT Project conflict occurs because a colleague’s feelings are not being acknowledged. When you take the time to acknowledge your team member’s problem, you can often prevent any further conflict. A team member on a project last year came to me with his feeling that things weren’t going right, that we wouldn’t be able to deliver. As it turned out the project was on track, it delivered on time, the issue had been a lack of confidence and by listening, really listening, I was able to coach this individual and show how the team had his back.
Sometimes just feeling that you've been heard is enough. So, try not to cut a team member short if they’re expressing their feelings. Slow down, listen, take as much time as THEY need to feel heard!
3 - Solve the issue not the symptom
Often, conflicts are not what they appear. Take Gav's project I mentioned earlier, it would have been tempting to treat the symptom of a bust budget by reducing overheads, cutting everyone's salaries, losing a team member, inflating future budgets, etc, but none of this would treat the underlying cultural issue. A team member didn't feel he could flag up the fact that they were working hard on something that was available to buy off the shelf!
4 - Delegate
As the project manager, are you not busy enough?! Whilst not entirely abdicating responsibility, you should seek to delegate conflict resolution where appropriate. You cannot 'down tools' to personally referee every conflict in your IT Project. When you delegate conflict resolution to a trusted team member, you give them a chance to grow and free yourself for more pressing matters. Make sure that they keep you in the loop though, you are still responsible!
5 - Seek compromise
Always go for Win/Win! When all parties leave happy, perhaps losing a little, but with a satisfactory outcome that chimes with the business goals of your IT Project, teams almost always emerge stronger. Compromise is not weakness and the best project leaders know where they have scope to shift for the greater good. There are times when you can’t budge, but when teams see you compromise when you can - they are more accepting of when you cannot.
6 - Go for consensus
Often conflict forces a third way to be found! Usually, new solutions appear that would not have crossed your mind, had it not been for the occurrence of your conflict. Don't come at conflict with an adversarial, entrenched point of view and you could come away with a much better IT Project outcome. Conflict is a cue for EVERYONE to open their mind!
7 - Get a mediator
Many Project Management as a Service providers can help when conflicts are not 'solving themselves'. Often, conflicts are the result of deeper issues and it helps to have them looked at by a fresh pair of independent eyes. With the best intentions, teams often approach conflict with their own baggage and see things in a way that may not be conducive to a resolution that is in harmony with the project's business goals.
Conflict within an IT Project, in one shape or another, is almost inevitable. When you implement effective conflict management practices and acknowledge the potential that conflict can unleash, you can turn disagreements into positive resolutions and your challenges into real opportunities.
Have you seen the video of 7-year-old runner Rudolph 'Blaze' Ingram who sprinted 100 metres in just 13.48 seconds?
It's fascinating to watch this young Florida athlete speed out of the blocks; and after clocking up thousands and thousands of Instagram views, as I write this, he has made the national television news here in the UK. To put this all in context, 9.58 seconds is the men's world record, set by Usain Bolt in 2009, and the women's record, set by Florence Griffith-Joyner in 1998 is 10.49 seconds.
Wow!! Those of you who know me will testify that I too, cut rather an athletic figure and for us IT Project Managers the similarities don't end there.
Reading more about this remarkable young man and listening to former athletes analyse the video it struck me how carefully planned every metre, almost every centimetre, of a 100-metre sprint is at the elite level.
When launching an IT Project, leaders and managers and their teams need to be equally quick out of the blocks and we too have to be meticulous and disciplined in our planning and execution.
The start-up phase of an IT Project is like a 100m sprint, over quicker than you think and what you get out of it at the finish tape is entirely dependent on what you do every step of the way. The 100m sprint is a pretty good metaphor for the first 100 days of an IT Project, especially for a new project leader within an organisation.
Let's run through it together.
So, the starter's pistol fires and you are off ...
0-25 Metres - Assess!
This is where you prepare and suss out your surroundings. By the 25th day, you should have completed your preparation and assessment phase. You should be engaged with key stakeholders, staff and organisational leaders. You should have learned what requirements and pain points need to be addressed first. Perception is reality and these early stages really can establish how you are perceived within the wider organisation - this will pay you back later if you get it right! When you establish strong relationships across the organisation, with influential executives who understand the value of the PMO, when you establish good reporting structures with these individuals, you will find that when you need support further down the track - it will be much more forthcoming.
By this stage, you should have assessed your resources and established what gaps you have and how you are going to fill them. Do you have the staff in-house to deliver the project, or will you parachute in resources from the Project Management as a Service sector?
I also like to identify a few key challenges that can be tackled and put to bed during the 100m sprint, your capability to deliver visible results early on can create a powerful perception within your organisation that often means you get the benefit of any stakeholder doubt later in the project...
20-50 Metres - Plan!
Around 20 days in, and still during this assessment phase your thinking needs to be split between the assessment phase and the start of your planning stage. The planning part of the project can last until about your 50th day - the halfway stage of your initial sprint!
Plans should be flexible and clear, simple but well defined, ideally, you are also be preparing an action plan for your second 100-metre sprint at this stage too.
Canvass the opinion of key stakeholders around this time also, share your draft plans with them and based on their reaction and enthusiasm make appropriate alterations.
At this stage, really think about the resources that you'll need to execute your plan. Recruiting from within and explore Project Management as a Service resources you may require to help deliver your project.
40-90 Metres - Action
Again, this stage overlaps the last and I cannot stress the importance of starting to act as soon as possible - if you feel confident to start executing sooner than this, don't hesitate! The greatest PMOs start implementing plans that they can alongside their long-term planning phase. I reckon it's not unreasonable to expect to complete one or two major milestones during this time - be bold!
Shout about ANY successful early result, your credibility increases with every early win, so don't be afraid to blow your trumpet! These results broker engagement across IT and business management stakeholders.
40-100 Metres - Measure
Measurement of the results of your actions should actually begin at the same time you start taking the actions themselves. The more you measure, the more you anticipate and the more you anticipate the more you succeed.
The final third of your initial 100m sprint should be focussed on creating firm foundations for the future and a launch pad for the next phase for your maturing PMO. This current project will fit within your wider project portfolio management (PPM) ambitions - now is a good time to measure that too!
The confidence and credibility gained throughout this first stage really pushes you on, not just in the physical sense either.
In one social media post, the star of our story, young Rudolph is pictured with a serious look on his face as he gets sets for a race and the caption reads 'My Father Told Me That You Win Mentally Before You Win Physically, I'm #1 Before The Race Start.'
I've seen projects succeed and fail based on the quality of mental preparation - teams that visualise success usually succeed and teams who visualise lots of problems encounter lots of problems. It's easier to achieve success that you've planned for and the earlier that success comes (remember those early milestones) the sooner they can have an impact on morale.
Of course, at this stage, the work of the 100m sprinter is done. For you, the finish tape of this initial sprint is just the beginning, but it will probably feel like less than 14 seconds have passed. Time flies!
Now, get your breath and run on!
Find out more about Project Management as a Service
You know what needs doing, you plan a budget, you set a deadline, you gather together a team and away you go - success is in the bag.
One of my Project Manager friends has a poster of a beautiful ocean liner, under a cloudless blue sky, on a calm turquoise sea with the caption - "Full Steam Ahead". That is how IT Project Management is, right?
Except, things go wrong. Calm turquoise seas have a habit of turning into violent snarling oceans, blue skies cloud over, there is a reason why that beautiful ocean liner has an equally beautiful row of lifeboats on its deck.
In IT Projects, the scope creeps, it turns out that you picked the wrong crew for your voyage or if you picked the right ones - they leave, you miss a deadline and the ripple effect means you miss another - and another, KPIs and actual performance become distant strangers ... lots of things can go wrong - and probably will. It's how you deal with it that counts.
One of my big takeaway lessons helping teams achieve successful outcomes in their projects over the last year is that few have the resilience needed to truly deal with the problems that can (and usually do) happen along the way. Full steam ahead is a great mantra until you come across an iceberg and it's the mantra you adopt at that point that will keep YOUR ship afloat!
So, with 2019 around the corner, I thought I'd share the lessons that I've learned over 2018 and share just two changes that could make a huge difference to your project outcomes in the future.
1 - Be an optimistic realist - Develop a sense of expectation that things WILL go wrong - and be COOL with that.
Expect failure and more importantly expect to learn from it - in fact, insist that failure teaches you something.
Having achieved this, become an Optimistic Realist in your reaction. Let me explain.
I work with Project teams all the time who are optimists, always have been, their glass is always half full rather than half empty and they expect good things to happen. Thing is, life and IT Projects are not always like that. Sometimes things go wrong. All the optimism in the world won’t stop a project with a creeping scope from running into serious trouble. I'm all for optimism but that won't stop your board from restructuring the business and making your project redundant. To be an optimist but EXCLUSIVELY expect things to go well can cause project teams to painfully crash and burn.
I've also worked with teams who are at the other end of the scale. Project leaders who are pessimistic and are constantly asking "What could go wrong?" or "What if this decision turns out to be a bad one?" You'd think that these types would be more prepared for the bad stuff, but it can be just as painful. The pessimistic PMs also have a tendency to talk themselves out taking a risk that could yield huge benefits or making a decision in case they end up getting it wrong.
I did an exercise with a Project Leader this year if you do catch yourself being pessimistic and saying, "What if this goes wrong?" or "What if I get this judgement call wrong" you might want to try it too.
This PM's usual reaction to his natural pessimistic outlook was to try to play devil's advocate and be an optimist who asks "OK, but what if it all goes right?" As this really isn't his nature, he never truly listens to that contrary voice in his head and so doesn't benefit from its wisdom.
Instead, we carried on the "things going wrong" scenario to its natural conclusion because ... well, things do go wrong. The darker outlook might be the one that does actually play out in reality.
This is where the Optimistic Realist position trumps both optimist and pessimist. Yeah, it might go wrong but by continuing it on, and by giving proper thought to how you'd deal with a problem and visualising solutions, you eventually come to a point where any potential problem just doesn’t matter. The optimistic realist in you knows that you will sort it. The more you practice this idea of things not going the way you planned and you being OK with that, the more the optimist in you can dominate your feelings towards and reaction to problems. You start to process them as just part of project life, as mundane and expected as the first cuppa of the day.
2 - Be REALLY cool with asking for help - EARLY
It’s true, your IT Project might not go to plan. By now though, you have learned to deal with it by being an Optimistic Realist. Good for you. Problem is that your beautiful ocean liner is still heading for that iceberg! You need all hands on deck to avert a catastrophe!
Often, project teams call for help too late. The Project Management as a Service sector is now so evolved that I believe any challenge you may face is catered for. You need help transitioning your project into the service delivery phase? You've got it! Need end to end, hit the ground running Project Management Office? You've got it! Need a little extra experience when the complexity of a project is beyond your in-house capability? You've got it!
BUT you do need to ask!
I've written before about why teams don't admit that there's a problem or that they are out of their depth or that they need help. It's usually driven by some kind of fear or ego and that's understandable, to a point. Admitting that you've bitten off more than you can chew with a project that you've already started may seem daunting but it's better than waiting until you're two or three months further down the line when the heat is really on! I think that "fessing up" that you need extra resources or help, or that you haven't a clue what to do next is a strength, not a weakness. Get help sooner rather than later, because later can quickly become too late!
One of my neighbours heard a knocking sound coming from the engine of her car and her solution was to turn up the radio. Weeks went by and after a while, EVERYONE in the street could hear a knocking sound. "You need to get that looked at!" we all said in a concerned, neighbourly way. She turned up the radio some more. A couple of weeks back the knocking noise just stopped. It was around the same time that her engine also just stopped, and she had to be rescued from the motorway. Ironically, the queue that her broken down car caused made the travel reports on the radio station that had helped drown out the racket! The moral of the story is that the most opportune moment to seek assistance is as early as possible.
So, as I'm writing this in December, that's my Christmas present to you (if you're reading this at some other time it's my Easter or Summer Holiday gift to you). Become an Optimistic Realist and ask for help - early. I guess, right now, there will be projects that are in trouble - I hope that they're being led by optimistic realists who anticipated the problems and are, at this very moment, dialling up their favourite Project Management as a Service partner. These are the projects that will make it to those Easter and Summer Holidays and beyond into service.
So, with that in mind, if you set targets for 2018 at the start of this year ... how are they measuring up? Are your IT Projects hitting the milestones that you hoped they would by this point? Or have they gone the same way as those New Year resolutions?!
Completely unscientific this, but a quick call around some project management friends reveals that most have projects that are lagging somewhat behind their ambitions.
Now, my specialist chosen subject, were I to go on Mastermind, would probably be the Project Management as a Service market. I find it fascinating how this sector has evolved to meet just about ANY IT project challenge and more and more innovative solutions are added to the 'brochure' every day. These friends with projects that are struggling know this, so I asked why they hadn't called to see if there was 'something out there' that could help.
The biggest reason was, cost’. There was a perception that PMaaS would cost too much. You know what? Project management as a Service can actually even help you reduce costs or in many cases lead to no net cost increase. It's one of my favourite myths to debunk. Even in worst case scenarios, the cost of using PMaaS resources is usually insignificant compared with, say, the cost of a failed project.
The other most popular answer was really interesting. They almost all said something along the lines of this ... "to ask for help would be an admission of failure or it would look bad on their own capabilities".
I asked who would judge them in this way. The most common reply was 'my boss', followed 'my team' or 'stakeholders', one friend even thought that the PMaaS partner they called might judge them in the way that a mechanic might if you took a badly maintained car in for a service.
This needs a reframe.
Firstly, I have never met a boss or stakeholder who judges anything other than end outcomes. OK if you turn up on delivery day with an incomplete IT project or one that is WAY over budget - you're gonna get judged. If, on the other hand, you parachute in PMaaS resources to deliver on time or on budget, you will be judged on that success and not by the means with which you achieved it. In most cases this is true.
Secondly, your team will not consider you a failure for reaching out, nor will they think that PMaaS resources are a reflection on their performance - unless you tell them that this is the case. They are more likely to be grateful that you have seen how hard they are working or that you have appreciated that the complexity of your project is perhaps beyond their current experience and capabilities. They will be glad of the assistance to get them over the finish line.
And thirdly, no-one from the PMaaS market will judge you. They are in business for just this kind of thing and they will be glad of the opportunity to serve. They want the business!! If they ridiculed or judged you, because of the state that your project is in then they probably wouldn't get asked back again and certainly wouldn't get the precious recommendation or referral from you that could lead to more work in the future.
Asking for help is a strength, not a weakness.
Seeking assistance with your IT Project is no different to being lost in a city that you don't know. If you are in a strange town to watch a gig or cheer on your team at a football match and you can't find the theatre or stadium - do you just keep walking down street after street in the hope that you get lucky? No. You ask for directions.
And what does the person you ask do? Do they laugh at you? Judge you? Do they tell you that they're too busy? Do they tell to buy a map or open the one on your phone? No, they just give you the directions. I love helping lost tourists get to where they want to be, I have even opened the map on MY phone to show someone the way before now.
Human beings are mostly wired this way and the proof comes in what happens after you give directions. You spend a good five minutes gesturing with your arms, pointing left and right, basically sharing your hard earned knowledge, even recapping (without being asked) in case they missed any of it ... and then what? The person says thanks and off they go. You don't get a box of chocolates or bottle of wine for your troubles, they don't take your name and address so that they can send you a Christmas card, they don't rifle through their pockets for loose change - they just go. What a user!! BUT, if a hundred yards down the road someone else said, "Excuse me, can you tell me how to get to the station?" - you'd stop and help them too.
You don't judge a lost tourist for being lost and no-one in the PMaaS sector will judge you for asking for directions with your IT Project either. Actually, they'll be happy for the chance to show off their knowledge!! AND the best thing is that, by hiring in PMaaS talent, you get to be a knowledge sponge!! In the same way that the lost tourist will now always know how to get to the station, you and your team will acquire new skills that you can take forward in your careers.
On-demand project management resources, which is basically what PMaaS is, allows you to flex your processes to your specific needs of your project portfolio at any given time. Sometimes you’ll need a lot of project management support perhaps to get past a difficult challenge and other times you can get away with less.
At Stoneseed, our PMaaS offer is a team of Project Management, Technical and Service Delivery Professionals, delivering services through a flexible, on-demand resourcing model. From strategy to service delivery, this cost-effective model for project delivery is underpinned by Stoneseed’s PMO, methodology and toolset. What that means is that whatever is holding your project ambitions back, we have the solution. Wherever you have got lost - we can give you directions! We love a new challenge, believe me, whatever mess you're in we are so ready to help you unpick it.
I find this time of year is a great time to assess IT Project performance against milestones and take corrective action if needed. Apart from anything else, we are about to head into 'peak sickness' season and knowing what your capabilities are and how much of your in-house resource you could afford to lose to a flu bug without impacting your projects is a great piece of insight to have. Having a PMaaS partner on speed dial as a backup plan is just sensible precaution.
Knowing that your IT Projects are on track and underwritten can allow you to fully enjoy whatever holiday season you are about to celebrate, safe in the knowledge that any fireworks that do go off - won't be in your project portfolio!
My friend's business is delivering financial services and he ensures that all his staff are suitably trained to provide the best advice, another friend's business is carrying bus passengers, his drivers know the local roads, what time their buses are due to arrive and how much the fares cost. This week I've been looking at holidays and hope that the firms I'm dealing with have brokered great relationships with hotels and airlines.
In each case here, the financial advisors, the buses and their drivers, the facilitators of dream holidays are the means by which their respective firms go about achieving their business goals. Everything that they do therefore is geared towards those goals.
Each of these also all relies heavily upon IT for delivery of their core business services, so presumably, IT strategies are similarly aligned. You’d think!
This sounds so obvious AND YET one of the most common reasons for IT Project fail is a lack of business case alignment.
Why? I guess because traditionally, IT's role in an organisation was a supportive or administrative one, not strategic at all! However, the increasing complexity of IT Projects, greater dependence on IT for delivery of business goals and the constantly changing IT environment means IT now has a much more strategic part to play. Unfortunately, in some firms, perception hasn't caught up with this reality.
Where it has caught up, where the two strategies are aligned, companies are enjoying much greater business results from their IT investment.
So how do you achieve alignment of IT and business strategy?
You can get independent advice, your trusted IT or Project Management services partner can usually deliver gap analysis around business case and a fresh pair of eyes can often see easy wins in this regard. Alternatively, here are six thought starters to consider.
1 - Early Engagement
To align IT Project and business strategy, leaders from your project management office (PMO) or enterprise project management office (EMPO) must be involved at the strategic planning stage. It's common sense, the work of project teams must be aligned with the direction of travel of the business, if strategy is to be delivered through IT initiatives, project leaders must be present when those plans are conceived. One of the greatest causes of a lack of strategic alignment is that senior-level managers are agreeing plans and THEN calling in the IT talent to implement them.
Early engagement of your IT talent leads to a natural evolution where business and IT strategy are able to grow together, each shaping the other.
2 - Don't Get Lost In Translation
In businesses where early engagement of IT leaders doesn't happen, many times the problem comes when a business strategy is translated into a tech strategy. Last year I consulted on a project where the C-suite decision makers had handed what they thought was a clear business change brief over to their IT team. Unfortunately, in mapping out potential technology challenges and working out technology and business dependencies, the essence of what the project was meant to achieve got lost.
The senior managers at the company thought in very different ways to the IT guys. As the CEO put it to me, the former "had a vision, a destination and a reason for the journey whereas the IT team were more pragmatic, they also knew where we had to go but hadn't bought into why."
The best way for IT teams to make sure that they are getting it right is to constantly ask questions. I have one PM colleague who insists upon a weekly catch up with project sponsors to make sure that what he is delivering is in line with business needs.
3 - Embrace Interdependence
The most aligned IT and business strategies are totally interdependent. I touched upon this before but the businesses that enjoy the greatest success aligning the two are those companies that encourage each to feed the other.
A great example I heard a couple of years back where a media content business planned to launch a smartphone app to keep up with their competitors. One of the IT project leaders was a user of a rival provider and she suggested a number of improvements but also several new business ideas based on her own experience of "what would be nice as a customer" of that rival. In other words, great business ideas should flow from the IT experts to the C-suite just as they flow the other way
I once heard it described like this by a brilliant CIO, her philosophy was that the business strategy should be full colour, shiny and inspiring and the IT strategy should be black and white, detail focussed and pragmatic. Success, she says, lies in bridging the two, the colour and the numbers, so that they become totally interdependent. There is no reason why the IT talent shouldn't also think in colour, in fact, they should be encouraged to.
4 - Governance
Anyone who knows me at all knows that I am BIG into governance. IT Project governance can often be the greatest influencer of success, and so it is with business case alignment. Many EPMOs and businesses start off with good intentions but business case alignment needs to be monitored and measured regularly. As soon as the two start to take different paths you need to know and adjust accordingly.
5 - Flexibility
As part of governance, business alignment needs to be flexible. What is ‘business case aligned’ today may not be in six months from now. If your IT Project has a six-month duration and, three months in, this is starting to look likely you have a decision to make.
One of my PM friends tells me of the first IT Project he ever worked on. After four months of working long weekends, and late into the night, the firm pulled the plug citing business case as the
reason. The project had been the perfect business fit when it was planned but the wider business landscape had changed mid-lifecycle because a competitor had totally disrupted the market. My friend says he was frustrated and angry but experience has since taught him that it is better to waste four months than six!
6 - Be Clear On Each Individual Team Member's Strategic Role
As previously discussed, business strategy is often conceived at c-suite level and then either gets lost in translation or not communicated downwards at all. The most successful strategies are the ones that everyone is bought into and aware of. Engaged personnel are more likely to ensure that everything they do moves the business closer to its strategic goal.
Being clear with every member of your IT project management team about where they fit into that vision and how their work will contribute can deliver massive returns and not just in business terms but morale and cultural cohesion can also benefit. In contrast, if your team members don't know their role and how it contributes to company strategy, it stands to reason that your business will find it harder to achieve desired goals.
When business goals are clear, aligning business and IT project management strategy and keeping the two together throughout a project's lifecycles improves success rates. More than that, the work you do has a purpose and a definite direction of travel. I find everything becomes less of a struggle, disputes are resolved quicker as you have a "blueprint" to refer to, everything seems to fall into place.
In conclusion, everything that your business does should be aligned with your business strategy and given its crucial role in delivering business strategy, that should be especially true of IT. How do you measure up?
Malc emailed to tell me that he had recently reframed his team's thinking on post-project delivery analysis. What he has done is pretty interesting and he says it is adding demonstrable value to the process.
"We always used to look back at what worked well during a project's lifecycle but not in nearly as much depth as what didn't work so well. In fact, we'd be more negative than that, especially if a project had failed to meet a budget or a delivery date we'd really drill down on what went wrong! If I put a ratio on this, I'd say it was weighted 5:1 in favour of looking back at what and how we messed up. We told ourselves that it was vital for learning, that we'd emerge stronger and I guess we did, a little. Actually though, we were mostly really bringing ourselves down."
I wonder how familiar this sounds to you? Perhaps, it's human nature to focus on the negative, perhaps we are hard-wired to believe that our greatest lessons are in the mistakes we make.
There may even be an evolutionary reason, one of the authors of a study 'Bad Is Stronger Than Good', Professor Roy Baumeister wrote that those who are "more attuned to bad things would have been more likely to survive threats and, consequently, would have increased the probability of passing along their genes." The article goes on, "Survival requires urgent attention to possible bad outcomes but less urgent with regard to good ones."
I think that you can learn a lot from dissecting the debris of where things didn't quite go to plan after an IT Project. Malc and his team have not abandoned this practice altogether, but they have shifted the fulcrum so that greater prominence is given to what went right and discovering the reasons for that.
Malc continues, "A year ago me and my team emerged from a post-mortem session feeling really sorry for ourselves. A project hadn't hit the bulls-eye, mainly because we'd not been strict enough managing scope creep requests and then, having agreed to changes, we had not been clear enough managing stakeholder expectations about their consequences. All of this conspired to quickly burn through a generous contingency budget, made the project late and one of the changes kind of watered down one of the original key business objectives of the project. Despite the fact that all the problems could be attributed to the stakeholder requests, all the scope changes were within our management and we had to take the blame rather than pass the buck. It was a bitter pill to swallow and we all went home feeling thoroughly cheesed off. It was a Friday night, not a great way to start a weekend!"
It's true isn't. Whenever I've put my heart and soul into a project and it hasn't delivered in line with my hopes and expectations I find it hard to be cheerful. I find my mind drifting back to what I could have done differently. I wonder about how I might act or think differently; if I'm not careful it can take over. Who hasn't woken in a cold sweat in the middle of the night when something hasn't gone to plan!?
It was feeling like this that got Malc thinking.
"There were five key business objectives on that IT Project. Four of them delivered in line with the brief and they would have been delivered on time and within budget, but all five objectives were interdependent. The fifth objective was the one delayed by scope creep requests, it was here where the budget overrun had happened, it was this that delayed overall delivery of the project. Suddenly, I started to see the project in a different light. Four-fifths of the business objectives had been met and independently they would have been on time, within cost forecasts."
The project had set out to streamline the IT operation across stock control and procurement, production, transport, customer services and finance, the plan being to create a transparent system whereby any team member could instantly get a real-time view of any part of the business operation, ie, The transport manager could check stock levels, sales administrators could check customer accounts paid in full before processing new orders, finance could check delivery notes for discrepancies before chasing late invoice payments. It was only really the accounts team that had "thrown a few spanners in the works" and ironically because of the odd tweak here and there it this part of the project that was not syncing with the dashboard Malc and his team had created.
"In isolation, four-fifths of the project delivered successfully! That's an 80% success story!" Malc started to tell himself.
Actually, in delivering these 'successful' parts of the project the team had done some great work.
1 - They had accessed resources from the Project Management as a Service market that had created efficiencies that had actually mitigated some of the delay caused by the scope creep from the finance department. Thinking about this some more Malc believes that the project would have been perhaps another week or two late had it not been for these innovations. In naval gazing over what went wrong, this had been completely missed. These were repeatable outsourcing strategies that could be used again in the future.
2 - There had been some really exciting collaboration with stakeholders outside the IT department to make sure that at each milestone the project was on track to meet needs. All departments had previously been operating as silos but now, not only were they liaising with the IT guys, they were communicating better with each other and they could check in an instant on parts of the business operation that previously would have meant waiting for an email or telephone reply.
3 - Malc noted that a couple of junior members of his project team had shown some real initiative and suggested improvements to the firm's stock control and procurement systems which to cut a long story short, meant that the company would carry less stock by automating purchasing to reflect orders received. Malc realised that other parts of the process could be automated to create similar efficiencies for the business.
As the night went on Malc's mood changed from one of melancholic despair to feeling re-inspired. He called each of member of his team to share his thoughts, the result being that everyone came back in to work on Monday in a better frame of mind than they'd left for the weekend.
"From that day we vowed to concentrate more on what went right and seek to repeat it rather than beat ourselves up about what we did wrong."
Malc and his team are not rewriting history to cast themselves in a better light, what they are doing is separating negative perceptions like "the project failed" from what actually happened, i.e. most of what the team did here worked really well and should be repeated.
Travis Bradberry, an emotional intelligence and writer, wrote an article for Forbes in which he recommends separating fact from fiction when considering negative events or thoughts, indeed he suggests actually writing down what you're thinking.
"When you find yourself believing the negative and pessimistic things your inner voice says, it’s time to stop and write them down. Literally, stop what you’re doing and write down what you’re thinking. Once you’ve taken a moment to slow down the negative momentum of your thoughts, you will be more rational and clear-headed in evaluating their veracity. Evaluate these statements to see if they’re factual," says Bradberry.
This is what Malc did. His team felt their over budget and late project, that had fallen short of a key objective meant it was a failure but when he committed his thoughts to paper that evening he started to see positive after positive staring back at him from the notepad.
He also realised that he had to be more assertive when considering scope change requests.
There are many studies that show that a positive outlook is better for your health. Who knows, maybe Malc is right, maybe the lessons for repeatable success lie more in what we got right than what we got wrong.
Whatever the truth, looking for the occasional silver lining certainly feels better than looking for the clouds all the time.
Find out more about Project Management as a Service
She's fine by the way, just wondering why despite best efforts, bad things happen. It's the same with IT Projects, you can think that you have all eventualities covered when something blindsides you on a Friday afternoon and suddenly you end up working all weekend to put it right.
My Facebook friend was having one of THOSE days! A parking ticket, call from kids school to say her son was ill, stand up row with her boss kind of a day ... and as I read the kindness and love in the replies it struck me that in life, as in IT Projects, there are some things you can mitigate against and some things that you can't! With the latter, it's how you deal it and who you can call upon to help that makes all the difference.
As my friend later said, the parking ticket could have been avoided by parking within the painted bay and the argument with her boss could have been avoided by "him not being such a jerk". The poorly child is different - you just deal with it (or call Grandma who becomes childminder and nurse for the day).
And so it is with IT Projects.
Just about every IT Project that fails has a clear and obvious reason why - in hindsight! The trick is to develop foresight, or as close as you can get to it, by learning the lessons each time and putting measures in place to avoid a repeat event in the future. Even then, bad things still happen to good projects and at that point, outcomes are directly related to the quality and speed of your response.
Let’s examine THREE BAD THINGS THAT HAPPEN TO GOOD PROJECTS ...
1 - SCOPE CREEP
Probably the single biggest killer of IT Projects. Everyone knows this, it's one of the first things you learn as a Project Manager ALTHOUGH you knew it even before that, it’s common sense.
I remember being sent to the shops to buy milk as a kid and being told I could get some sweets with the change. Actually, as well the sweets, I also bought a comic but not before I'd properly and thoroughly perused all the titles on sale. When I got home, the pot of tea (for which I'd been sent to buy the milk) had stewed and gone cold and I didn't hand over the expected amount of change.
It was my first experience of scope creep! Throw in more tasks and spend more money than planned and any project will take longer and cost more. We've all instinctively known this forever but from stakeholders to project teams we have all been guilty of allowing scope creep to happen.
AND sometimes, it's necessary! If the market changes mid-project and you need to react to remain relevant, or really exciting additional deliverables are identified, it would be foolish to stick rigidly to your original plan. It would also be foolish to expect the rules of the original plan to still apply. You may need extra resources from the Project Management as a Service market, you may need extra time, you may need to renegotiate the budget ... there is always something you can do!
2 - LACK OF LEADERSHIP EXPERIENCE
Last year, we were called to consult on an IT Project that had been planned, scoped and budgeted perfectly. Soon though, things had started to go wrong; staff fell ill and the remaining team members got stretched trying to cope, a list of stakeholder "must haves" began to land in the Project Manager's email inbox and, in the melee, the team lost focus on the agreed outcomes of the Project.
It was actually the PM who reached out admitting that he was out of his depth. I love this self-awareness!
There is no shame in admitting this. Each project varies in complexity and each project manager has his or her own level of experience, to which they are adding all the time. The Project Management as a Service market has reached a maturity now that can provide end to end Project Management services for more complex projects and, of course, fill gaps like staff shortages.
Perhaps the greatest thing you can do here is become a knowledge sponge! If you are hiring in more experienced resources make sure that you learn from them!
3 - LACK OF STAKEHOLDER ENGAGEMENT
An IT Project Team Leader I know called me recently to say, "David, I honestly think that if we stopped working on this project and didn't deliver it - no-one would even notice."
My friend works in an industry where a lot of consolidation has occurred of late, companies have merged, IT architectures have been integrated, priorities have changed. The project in question is a customer facing app that was designed to disrupt the market and challenge a larger rival. The problem is that after a hostile takeover that larger rival now owns my friend's company and many of the original sponsors and stakeholders have moved on or changed their role or focus.
In this case, stakeholder engagement vanished overnight. It's not always this dramatic, of course, sometimes long projects can lose the attention of stakeholders along the way it is the job of the project team to communicate regularly and in an engaging way so that delivery is eventually met with a fanfare and not a whimper of vague interest.
In the case above, I have challenged my friend to approach the business decision makers at the new owner and ask if the work he is doing is still relevant to the post-takeover business strategy. I think that this pro-active approach will earn him more credit than delivering a project six months from now that no-one even knew, or remembered, was happening!
There is always something that YOU can do.
In conclusion, bad things do happen to good projects and some are under your control and others are not. However, what you do have control of (in every circumstance) is how you react and you have the power to make that call to ask for help. The Project Management as a Service universe is expanding on a daily basis with new solutions to the challenges that we all face from time to time.
There is always someone on the other end of a phone or an email who can help.
So, like those replies to my Facebook friend, let me ask ... "You OK?" ... "How can I help?"
Find out more about Project Management as a Service]]>
“Now it's us facing a great change and if we don't we'll become increasingly irrelevant."
In spite of this seemingly negative line, the theme of his email was really upbeat. He was telling me that he had realised that his traditional project management methodologies had been delivering diminishing returns and so he had taken a helicopter view of his (and his team's) whole approach to project management.
The conclusion was that different projects might need different approaches.
Now, you may laugh at this, it may not seem like a ground-breaking observation to you. Like many IT environments, my old friend has worked in a space where, for years, each IT project could be successfully delivered with a tried and tested approach - "Waterfall works" might have been their motto! Project after project benefitted from a systematic formula, everyone knew what they were doing, what was expected, how to proceed through the various stages, and time after time projects were delivered successfully. Slowly though, over time, the market changed. Increasingly projects needed alterations during their life cycle to reflect market realities, the business became more IT led and its strategic goals shifted more to an e-commerce model. Then, a complex project appeared that needed an altogether more flexible, more iterative approach. He realised that he and his team had been working in the same way for so long that their skills were no longer aligned with business needs.
He carried out a skills audit and based on current needs, created a gap analysis. He looked at project trends to forecast what skills would be needed in the future and they had an honest look at the certificates on the wall to see how well their qualifications measured up against projected need. He said it was "the most depressing week of our lives" as they realised that within a couple of years they might be, in his words, "extinct"!
They had to do something. He told me, "We had to either give up or give it our all!" They chose the latter. They learned new skills, first Agile, then Lean and afterwards a whole toolbox of methodologies and approaches - remember all they'd ever needed was Waterfall. Now, when something comes along that that is outside of their newly extended expertise they reach out to the project management services market for resources that complement their own capability - something that their "waterfall works" previous selves would never have done.
I found the story interesting because I am hearing many Project Managers say that they feel their role is changing. Actually, last year a PMI conference adopted a theme of "Adapt or Die?
Transforming Project Management to Embrace the Challenges of Tomorrow", with a stated objective of preparing participants "for the significant changes that are already happening, and will exponentially increase, and how this impacts our role as project managers." The conference, in Norway, focussed on how projects in the future must mirror changing trends and adapt in terms of scope, domain, content and schedule to an ever-faster business changing world. It is clearly deeper than just anecdotal evidence from a handful of my contacts.
Another of my CIO contacts has undertaken a root and branch review of their entire Project operation, realising in the process that project management was no longer just the domain of project managers. He told me, "There were a lot of different fingers in the pie, the business had evolved to a place where some IT projects were being green lighted to be initiated within and by individual departments. The IT Project team's job had been reduced to advisory, ensuring compatibility with other business IT systems and troubleshooting when things went wrong. The project team has had to shift its idea of where it fits within the business"
In Australia, Stephen Callaghan (Agile Transformation Lead, AGL) has noticed similar trends, "There has been much talk about the traditional role of the project manager dying and, from my own experience, the role is disappearing in many of the organizations I’m engaging with. For example, I currently work for a large utility company on a $300m+ transformation programme that used to have dozens of project managers and now we have none at all. That was a transition that happened in less than 12 months," he told AXELOS (a UK government/private sector joint venture to develop best practice).
So, the job title of 'Project Manager' appears to be evolving into different roles across businesses and project teams are having to react fast. The rate of change so far, though, is just the tip of a very big iceberg.
Stephen Dowling (founder of ETM Consultancy and Training) told AXELOS, "What is coming is utterly phenomenal. Over the last 30 years of technology change, it’s estimated that we’ve only seen 1% of the change in technology. In the next thirty years, we’re expected to see 99%!"
IT Project Management does seem to be where the greatest disruption is set to occur, I spoke with my friend who works in project management in construction and he tells me his role remains unchanged and sees no sign of anything changing in the future, if anything his remit is expanding and he is taking on responsibilities from other departments rather than the other way around.
Wise CIOs, Project Leaders and businesses are making preparations. Dowling said, "People need to wake up and see that the world is changing really fast", adding, "Organizations need to be open to more agile ways of working. Currently, the levels of people’s engagement across the world is quite shocking – we need to unleash their potential. When people enjoy what they do, know why their doing it and are empowered they become more engaged, motivated and connected."
Callaghan agrees, "You need the ability to pivot very quickly. Speed is of the essence right now and organizations need to be aware that competitors are coming at them from all sides. They need to morph and to take advantage of the situation; to know where the pivots and threats are going to come from."
I don't know whether the ratio of technology change over the last 30 years compared with the next 30 years will be 1:99, that sounds (paradoxically) both Orwellian and utterly plausible! What I do know though, and there is some comfort in this, is that the Project Management as a Service universe is expanding with solutions at a rate that is keeping pace with the IT project industry finding
new challenges. So, however, your business and your IT Project operation evolves, there will be best practice help available.
In conclusion, like with most change, it's how YOU react that determines your destiny. Nothing lasts forever, I remember the postman once telling me that he had a job for life, I often talk with him about this as he pulls me a pint in one of our local pubs. The point is, things change, you have to either adapt and embrace it or quickly become obsolete.
Find out more about Project Management as a Service
Anyway, it turned out that "Jim" wasn't really an "ogre". He was just really assertive. The thing with assertiveness is, like with most things, there's a good and a bad way to go about it.
I recall an IT Project Leader launching a stapler across an office once when things weren't going right. Everyone from team members to stakeholders were scared of him. He'd have ended up in front of the HR Director these days but, back then, it was just accepted that this was how this guy was. He got results, wasn't afraid to say no to a scope change request and you didn't make a mistake ... because you were terrified of the consequences.
But that's not assertive. That's aggressive!
And there's a difference.
Workplace cultures, on the whole, are more friendly now and the days of shouty leaders barking orders and thumping desks are a thing of the past - and that's a good thing. However, over the last ten years, or so, I have progressively seen assertiveness being bred out of a lot of IT Project Management talent and that's not so good.
Bud Bilanich, author of 'Climbing The Corporate Ladder' may have stumbled on the problem. He says, “Don’t focus on being friends with the people you lead.”
In many IT teams, managers have been promoted through the ranks. That means they now lead their friends and being assertive with someone you used to sit alongside can be hard. We have provided end to end project management resources for many teams over the years that lack assertiveness for this very reason. External talent doesn't come with any emotional baggage. Ultimately though, if this is causing you a problem you are best to address it. You're there to make decisions, not friends, and some of those decisions need you to be assertive.
Bilanich advises, “Focus on leading them.”
I wonder, as well, whether workplace cultures have evolved to a point where the lines between managers and those under them are blurred. Open plan offices mean that many bosses and their staff work together without walls. I tell you, getting called into your manager's office back in the day was more of a big deal than being asked to scoot over to the gaffer's desk at the end of the bay!
Set against this backdrop it's perhaps easy to see why assertiveness is on the wain.
"The important thing to do is to stand up for yourself in a manner that doesn’t trample on other people," Bilanich says, "This is a good working definition of being assertive."
I do believe that it's an important skill to have in your success toolbox, so, can you be assertive without everyone you work with whispering about what a big "ogre" YOU are?
Of course, you can. I'll come onto how, but first let's consider why assertiveness matters.
1 - Sometimes The Project Needs A Gentle Shake!
The trouble is, as business cultures have become less hostile, many project teams have lost the knack of how to say 'no', how to speak up and how to rock the boat when necessary.
In her book "Extreme You", Sarah Robb-O’Hagan identifies many ways to practice assertiveness without being seen as an ogre. One of them is simply learning to speak up. Have you ever been in a meeting where you get frustrated that no-one is bringing up the big problem, the glaringly obvious issue? Sarah explains that this could be your cue to speak up. Surely, if no-one else has noticed the problem, or worse is afraid to speak up, it's your responsibility to flag it. If you agree, well done, you just became a bit more assertive.
Who hasn't seen a Project slip because no-one was willing to put their head above the parapet?
2 - Your Career Needs Assertiveness
In his blog post, "How to Be Assertive At Work (Nicely)", Andy Kaufman writes, "Being more assertive with colleagues doesn’t mean you must be the person who’s always talking. But being quiet is easily misread."
He's right. I've seen talented Project Managers passed over for promotion because they are not seen as leader potential due to their lack of input at meetings.
Kaufman also claims that less assertive team members earn less, citing research from Harvard’s Teresa Amabile who published a study called “Brilliant But Cruel” which suggests that if someone is too nice, it is assumed that they're less competent and therefore less well remunerated.
3 - It's Your Right And Responsibility
Are you a Leader? Then you have been given the right to lead by whoever pays your wages! In fact, it's more than a right, you have a responsibility to your stakeholders.
But it's not just leaders that have the right and responsibility to be assertive, it's everyone who clocks into work on an IT Project. Imagine something goes wrong and you noticed it but said nothing. Surely that's worse than being known as the colleague who always has a different view, or always flags up a potential mistake, error or flaw.
If you spotted thick plumes of smoke billowing out of the kitchen at your workplace, you'd run to the nearest break glass alarm point and sound the bell. You'd cause everyone to down tools, stop work and evacuate to a safe place. It might be nothing, a colleague burning toast, but you'd instinctively feel a responsibility to others in the building. That would be a pretty assertive action and you'd do it in a heartbeat. So, you have it in you. You just need to give yourself permission to use it when you think you see metaphorical thick plumes of smoke billowing out of your IT Project!
It is a remarkably fine line sometimes. In "How to Be More Assertive at Work (Without Being a Jerk)", Melody Wilding writes, "Put simply, being assertive is a happy medium between the two extremes of aggressive and passive. While aggressive people adopt the “my way or the highway”
stance, coming off as hostile and abrasive, passive people can be pushovers, giving up their power and allowing themselves to be taken advantage of, creating a surefire recipe for burnout and resentment."
She's nailed it. Have you noticed that assertive people tend to be less stressed? It's not because they get their own way the whole time. It's because, on the whole, they seek solutions that work best for everyone. They have their say, they put the case for an alternative strategy or they point out the flaw and if their suggestion isn't the one chosen, at least they know they've been heard and can progress with equanimity. Similarly, assertive leaders seek alternative views before deciding.
Maybe that's the key to assertiveness. Engagement. If your whole team feels they’ve had their say and buys into the reason why you're being assertive, half your job is done for you.
Find out more about Project Management as a Service
As I write this we are rapidly approaching the end of quarter one. I cannot believe how quickly the year is zooming by. With the first quarter under our belts, I've noticed three distinct IT Project Management trends that I think are exciting (and to be encouraged) as we approach the rest of 2018.
By the way, it doesn't matter if you are reading this in June or September or even a year in the distant future, nor does it matter where you're at maturity wise, these ideas are worth adopting at any point - it just so happens that I've seen something of a spike in the first three months of 2018 and I wanted to note it so we can all continue to make them happen.
1 - Prioritisation Has Become a Priority
If you were to check back over the years, the percentage of projects delivered on time or delivering the expected benefits has always been rather low. Can you recall either measure returning a success rate over 50%? Me neither!
The problem, in my view, has been one of prioritisation. Too many projects, too few resources.
It presented some tough choices for teams. Do you continue to try to manage many projects, knowing that you'll deliver a third of them well (and two thirds not so well), or do you manage fewer projects and super focus on delivering them to the best of your ability? Both options had their flaws, you couldn't always guarantee which projects would fall into the third you delivered well, I've seen key, strategically aligned projects fail because attention got switched to less important projects with arbitrary, “more urgent” deadlines. Also, if you start to turn down projects it's not long before the board start to question the value of having a PMO!
The Project Management As A Service (PMaaS) market has delivered a brilliant compromise that I am seeing more organisations adopt in the first quarter of 2018.
Better prioritisation is allowing CIOs and Project Leaders to focus in-house talent where it is needed most. When you do this, capability gaps become apparent and these can be plugged with resources from the PMaaS market, whether that is individuals or teams or full end to end project management.
Instead of turning down projects, teams operating like this are expanding their capability, those that I am working within this way are on course to deliver successful projects.
And on that ...
2 - The Definition Of Success Is Changing
The measures of success that we've used for years are no longer enough on their own. Scope, time and budget all still have their place but as competition ramps up, the Project Management profession needed to drill deeper. The value of what a project delivers against what it set out to is increasingly important. I am happy to see clients and industry friends alike finding ways to measure expected versus delivered benefits.
I think that this may have been prompted by the PMI choosing to focus on levels of what they called "benefits realization maturity" (as well as the tried and trusted measures) in their Pulse of the Profession report for 2017. They were able to identify the gulf between "champions" and "underperformers", the former having higher project success rates (92% versus 33%).
It may be the PMI's adoption of "benefits realization management" as a measure, of course, it may just be a coincidence. However, I am seeing this success yardstick increasingly used by IT Project teams and it is no coincidence that teams with this focus are enjoying more successful business aligned returns.
The "collective process of identifying benefits at the outset of a project and ensuring, through purposeful actions during implementation" was a trend that started in 2017, when almost a third of organisations (31%) reported high benefits realisation maturity. I am encouraged to see anecdotal evidence that 2018 has, so far, seen a further rise in its adoption.
3 - IT Project Management Has Edged Closer To The Top Table
IT Projects feel like they have greater "c-suite" representation than ever before, three IT Project Leaders I've known for years have taken newly formed roles within their businesses as CIOs this year already, giving me an exciting sense of the direction of travel for the profession.
Spring 2018 heralds the opening of applications for the Register of Chartered Project Professionals. The Association for Project Management (APM) has officially become ‘The Chartered Body for the Project Profession’. Royal Charter status gives the profession a certain gravitas and I get a sense that more businesses are now taking IT project management a lot more seriously!
One business I know, that has 'tinkered' with project management resourcing projects on a pay as you go basis through PMaaS, just established its own Project Management Office (PMO). Furthermore, a number of organisations who previously weren't benefitting from even basic Enterprise Project Portfolio Management have taken a step towards greater maturity, better governance, more defined gating of project stages, tracking of benefits, methodologies, etc.
All in all the signs for the rest of 2018 are very encouraging! I hope that you are a quarter of the way to achieving your 2018 IT Project goals; if I can be of any help in the remaining three quarters, or you've spotted any IT Project trends emerging, I'd love to hear from you.
Find out more about Project Management as a Service
We'd been comparing our backstories, him fresh from college, ink just dry on his certificates and excitedly starting his first placement, hence the question. With a few more years under my belt, I had to think about my answer. It was only later that I realised that, actually, you never stop training and you never stop learning.
Furthermore, of all the IT Project Leaders I know, the greatest ones are all I learners.
They are always bringing something new to the table and they encourage their team members to do the same, whether it's reading, listening to a podcast or streaming a TED talk they are sponges for new information and it shows in their performance.
They do something else though.
They seem have worked out a better way to learn and they execute it brilliantly on a daily basis.
1 - They Teach What They Have Learned
They pass on what they have learned, they discuss it, debate it and each time they do they digest the learning further. Studies have shown that, when you teach something that you have learned, you digest it better yourself. As Steven Covey, author of The 7 Habits Of Highly Effective People once said, "You learn by teaching." In fact, Covey is a great example of this, he recommended not that rather than just reading his books, you should teach what you have learned within as soon as 24 hours.
2 - They Have A Wide Subject Matter Scope
They seek to learn from outside their day job. The brain is a complex muscle, in the same way, that you wouldn't go to the gym and just work on a part of your leg, you need to exercise different parts of your brain. Most project managers read a lot about project managing, great project leaders do this too but they also read about a broader scope of subjects.
The last time I met with one, for instance, he was reading about how farmers were trying to reduce methane gas emissions from their cattle!! I mean, how random is that at first glance?! What it does, though, is allow your mind to place its energy elsewhere. When you start to imagine how to stop cows accelerating global warming you leave your subconscious mind to deal with what to do with the latest IT Project challenge you're facing, and it seems that your more laid back subconscious mind is sometimes better at this. Ask Archimedes! Would he have had his eureka moment had he not stopped work for a soak in the bath?
So, where do you access learning? Here are the four most popular knowledge channels cited by the leaders I talked with.
Leaders Are Readers
Former US President, Harry S. Truman once said, "Not all readers are leaders, but all leaders are readers." This is the case with all the IT Project leaders who shared insight. They read all the time, books, blogs, white papers, industry journals.
Leaders Are Listeners
Most of the IT Project leaders I spoke with download podcasts regularly, some industry specific but others that are generally motivational or just interesting and thought-provoking.
TED talks are brilliant, aren't they? I recently stayed in a hotel and among the options on the Smart TV was an array of TED talks which I devoured with delight.
When was the last time that you attended a seminar? If the speaker was really engaging I bet that you came away buzzed and wanting to get back into the office and put what you learned into practice.
Another great place to attend is an adult learning class or workshop type event. A couple of leaders I spoke to regularly attend lessons that are totally removed from their day job ... cookery, woodworking, even knitting were examples I was given! There is method in this - when you challenge yourself and step out of your day to day you exercise those different parts of your brain and open yourself up to new creative potential.
One Project leader I chatted with had a great perspective on all of this. He told me that while the information attained from all this reading, watching or listening is great, for him, each of these channels gives him an opportunity to spend quality time with the planet's smartest people. I love that.
So leaders are readers ... but there's something else that I've noticed.
The greatest learners are also the greatest earners. There's food for thought. See you in class!
Find out more about Project Management as a Service
What a brilliant idea for us in IT Project Management to steal! I think it might be a really useful way to keep budgets in check so with that in mind I present ...
The Mini-Budget And 5 Other Ways To Keep IT Project Budgets Under Control
1 - Stricter Scope Change Control
Do you agree that scope creep is the biggest reason that IT projects fail to deliver on-budget?
Keeping scope creep under control is, therefore, obviously your greatest weapon in the battle to keep costs in check. Scope changes are always requested and agreed to with the best of intentions - no-one likes to says "no". BUT uncontrolled scope creep can at best cause overspend and at worst cause projects to get cancelled when costs spiral. Keep control of those "hey wouldn't it be good to have" requests that come in during the life cycle of your project, establishing a practice of passing scope change decisions to an executive-level stakeholder is a good way of not being the guys who always says no!
2 - The Mini-Budget / Mid Term Progress Statement
In Project Management you agree a budget before you start. Part of how the success of your project is measured then depends on how close you get to that budgeted figure. As mentioned already, if the scope creeps you can easily end up looking at a budget over-run.
How about an agreement that any scope change request should trigger a mini-budget discussion? You could set out the cost implication of a stakeholder request and negotiate new terms with the sponsor. Once the new budget is signed off and new terms agreed you can progress in confidence.
3 - Have Two Sets of Accounts
One of my PM friends prepares two quarterly mini-budget style progress statements. They have been invaluable in keeping to budget.
One report details savings that have been made against the budget and milestones that have been achieved. It's governed by a strict ACWP KPI (actual cost of work performed) and gives a very transparent real-time insight into the health of the project. Crucially, this is just for internal, project team consumption.
The second is for stakeholders and the wider business, it's a carbon copy of the first in terms of progress updates but the budget savings are replaced with a line that simply says "On Budget".
He explains that he once made a considerable early saving by efficiently resourcing part of a project through the Project Management as a Service market but made the mistake of declaring this to the board who promptly slashed his budget. He now keeps very quiet about mid-life-cycle savings and, instead, filters them into a contingency fund.
I suppose what I'm saying is that your mini-budget should reassure stakeholders that you're on track whilst giving you a "hush hush" accurate costs vs budget status. As my friend says, "Keep under budget, under wraps!" Until delivery day, that is, and at that point shout it from the rooftops!
To be clear though, if a part of a project is running over budget he is COMPLETELY transparent about that at the earliest possible opportunity but underspend news can simmer.
4 - Have A Contingency Budget
OK, so you're keeping those little budget wins to yourself. Now, give yourself some freedom to have them in the first place! Budget for the unexpected.
Your IT Project is vulnerable to surprises, from internal factors like scope creep or a key team member falling sick to external stimuli like fluctuating prices of products and services to volatile foreign currency exchanges if your project crosses continents.
Sounds obvious but the more you budget for the unexpected the better prepared you are to deal with it!
One of my PM friends tells the story of how he delivered two similar projects once, for practically the same cost. After the second project he was hailed a hero and had his face plastered all over the company's intranet, but after the first project, he had to sit with the Finance Director and justify an overspend. Similar projects, similar costs, different perceptions. Of course, the biggest difference was that he increased cost estimates for the second project allowing him to deliver well under budget.
5 - Be A Vendor SuperVet
I don't mean create bionic limbs for your suppliers like TV 'Supervet' Noel Fitzpatrick does. Being a Vendor Supervet means casting a realistic eye over your supplier quotes and taking a view on the likelihood of your vendor keeping to those obligations. Like you, your suppliers are prone to external factors and a quoted price at the start of a project may not be viable further down the line. Ensure that your vendors can deliver as promised and have a "plan b" ready in case they can't.
A good old fashioned thorough checking of contracts is needed! Make sure there are no nasty clauses that lock you in even if prices rise. A multi-sourcing partner can help with this by pre-vetting vendors to protect you.
6 - Try To Break Your Project EVERY DAY
I remember a project manager who used to come to work with a mantra of "how can we break our project today". He wasn't an IT Project anarchist, a crazy madman who should have been escorted out of the building though. his philosophy was that the further a project progresses with an inherent flaw, the more it costs to put right.
If you only test your IT Project just before delivery and there is a problem with the work you did back in week two then the task of unpicking it all to correct the problem can be complex and costly. Test early, test often, test well.
When you test early and you uncover errors you can take corrective action before they snowball into huge problems. It also acts as a cheerleader. 99 times out of a hundred there will be no problems and you and your team can rejoice in the effectiveness of the work you are doing!
Keeping an IT Project on budget isn't rocket science unless you work for NASA, but it is crucial. These six measures can really help and, of course, there are many more - I'd love to hear how you keep your IT Project costs in check.
Looking beyond the rather overblown spectacle of the ceremonies themselves, there are actually some great IT Project Management lessons to be learned.
1 - It Doesn’t Always Take A Big Budget And Traditional Methodology To Succeed
I remember thinking this when "Dallas Buyers Club" got 6 nominations in 2014 including Best Picture, Best Original Screenplay, Best Actor and Best Supporting Actor. It won 3 of them, Matthew McConaughey and Jared Leto took home the actor gongs but, more interestingly, the film won Best Makeup and Hairstyling.
The makeup budget was only $250.
Perhaps the best Oscars illustration of "It Doesn’t Always Take A Big Budget" is to compare the budgets of the most recent Best Picture winner (Moonlight) and arguably the most expensive winner, from 1998, Titanic. A Reddit user, Joe Falchetto, recently adjusted the budgets of the last 50 years worth of best pictures for inflation and the chart he produced is astonishing - Titanic cost $200m (about $302.6m in today's money) - Moonlight cost just $4 million.
Similarly, IT Project success doesn't have to come at a high price. Oftentimes, a cutting-edge, targeted, Project Management as a Service solution can cost less, for example, than using in-house talent who can then be better deployed elsewhere across your portfolio and gap analysis can help you measure your resources against your ambition.
A Project Management analysis can identify ways to work cheaper and smarter with the same or better results - "Dallas Buyer's Club" was made on a budget of $5m, in less than a month, using only natural lighting!
2 - Relevance Is Key
I remember Braveheart winning Best Picture in the mid-90s, beating Apollo 13 which many people thought would win it. I have seen both movies recently and Mel Gibson's Scottish accent has not stood the test of time as well as Tom Hanks' "Houston, we have a problem". If the two movies were released today, the latter would still be worthy of a nomination, the former ... possibly not.
I saw Braveheart back in the 90s and, although Gibson's Scottish brogue attracted some ridicule, it didn’t affect my enjoyment of the movie - maybe I was comparing it to Robin Williams' Mrs Doubtfire. More recently, maybe Mike Myers' Shrek has since raised my awareness of what a Scottish accent in a movie should or shouldn't sound like but when I watched Braveheart years later, I just couldn't get past it and because of that, the film didn't feel like an Oscar winner!
If a film that won an Oscar back in the day can stink today, why should it be any different with technology and IT Project methodologies? Be relevant!
3 - Moonlight/La La Land - What Can You Learn From Last Year's Oscars Mix Up?
Do you remember this last year? Watching the debacle back you can see something is wrong from the start. Poor Warren Beaty looked very confused when he opened that envelope and rightly so. He was there to announce best picture and the card was for the winner of the previous category. He looked to co-announcer, Faye Dunaway, but she misread his pausing as an attempt to prolong the suspense, looked at the card and blurted out the winner ... La La Land.
Three lessons from this ...
i) Get It Wrong - Right!
The apologies were thorough, there was no spin. In a fortune.com post "Oscars 2017: What Leaders Can Learn from the Best-Picture Mixup" Lauren Stiller Rikleen of the Rikleen Institute for Strategic Leadership writes, "the lesson leaders of any organization can take away from this is: own your mistakes; fix them; apologize for them; investigate them, and do the best you can to move on and learn from them."
ii) Make Everything End User-Friendly.
Did you see the card that Beatty and Dunaway had? The award category was written in a tiny font at the bottom of the card and printed gold on red on the envelope. Not the easiest thing to read. It was a case of style over substance. Big font, black on white every time for me (as the end users, having been given the wrong envelope, the mistake would have been easy to spot with clearer cards)!
Same with IT Projects. Thinking about how the end user will access your completed project to deliver business results really pays off.
iii) Shout If There's a Mistake
Easy to say, but Mr Beatty could have prevented all that confusion by asking one simple question - "is this right?" You could see in his eyes he knew something was awry. When IT Projects go off course, the thing that caused the fatal problem has, more often than not, been noticed by someone but not acted upon. Create a culture where it's OK to flag up when you think that something is wrong.
4 - Get The Casting Right!
This is becoming increasingly important.
Animated movie director, Andrew Stanton once said, "Working at Pixar you learn the really honest, hard way of making a great movie, which is to surround yourself with people who are much smarter than you, much more talented than you, and incite constructive criticism; you'll get a much better movie out of it."
I love this quote and what a great way to approach casting an IT Project too!
IT budgets, more than ever, now necessitate that teams work like well oiled, focussed machines. The members of your team need to get on and work well together but you also need the skills of your talent to match those needed by your Project. More and more, these can differ from project to project and often from task to task within a project. Few businesses are able to have the luxury of idle hands waiting for their specialism to be needed, for this reason, many hire best fit all-rounders.
There is an alternative that delivers key specialist tasks as and when you need them. The Project Management as a Service market can provide skilled individual, teams and even end to end Project Management. It has never been easier to get the cast list just right.
5 - A Good Plot
Every movie that has ever won best picture has this. A great beginning, middle and end.
Your IT Project has a story arc too created in the planning stage. You meticulously plan each phase like the most gifted movie writer crafts each scene and you execute your plan as meticulously as any movie director.
Where IT Projects differ is plot twists.
In movies, plot twist are written and rehearsed. In IT Projects, we rarely have that luxury. An IT plot twist tends to blindside you from nowhere on a Thursday afternoon. It's how you deal with the plot twist that separates the winners from the nominees - scope creep, unforeseen overspends, talent calling in sick, etc, etc are all plot twists for which you can turn to the Project Management as a Service in search of a solution.
Complexity is another area where movies and IT Projects. I mean, sure, movie people probably push the boundary of their own creativity but in our world, that boundary is often pushed for us. Business needs might force us to step out of our comfort zones and sometimes creating the "plot" for these is harder but arguably more important. Again, the Project Management as a Service can solve this with tools and people on demand.
6 - No-one Remembers The Runners Up
Perhaps apart from La La Land, after the 2017 debacle, can you remember many other films that were Oscars runners-up? Or actors or actresses? It's the same with FA Cup Finals, Wimbledon, or the winter Olympics - Torvill and Dean won the 1984 ice dancing gold but can you remember who won silver? Nope.
And so it is with IT Projects. Winners get remembered. Give yourself the best chance of winning ... the right resources, the right time horizon, the right budget, space for the unexpected, a great cast and supporting cast, a compelling, relevant story and a shared vision.
Finally, and most importantly ...
7 - Be Sure To Thank Your Spouse
How often do you hear actors thank their other half? A lot! It can't be easy being married to an actor!
IT Project spouses put up with a lot too. Late night, last minute weekends, taking work home, waking in the night with a eureka moment ... being married to an IT Project professional probably ain't that easy either. I often wonder whether if we give our other halves enough credit for the sacrifices that they make to allow successful outcomes, not just individually but the companies we work for.
I recently heard of a firm that booked a restaurant table for the partners of and each member of a team who had been burning both ends of the candle to ensure that a software rollout happened on time. It was their way of saying thank you and telling the partners how much the business appreciated those sacrifices.
If you're a CIO or a Project Leader, it's worth remembering that every hour your talent spends on your project is an hour that they're away from their partners and families - reaching out occasionally to thank these supporting cast members is not just a nice thing to do, it oils the wheels for the next time you have to ask for last minute overtime.
In conclusion, while most of our hard work doesn't get recognised at a swanky awards night with a goodie bag worth thousands of dollars, it's great to work on an IT Project that feels like an Academy Award winner! No-one ever sets out to make a movie that wins more Razzies than Oscars and the same, metaphorically, is true of IT Projects.
With the right planning, preparation, supporting cast and all the other things and more that you get right every day, ... I'm thrilled to announce, the winner is ... you.
Find out more about Project Management as a Service
boxofficemojo.com - moonlight
boxofficemojo.com - titanic
fortune.com - oscars 2017 moonlight la la land
A poster of Lord Alan Sugar just appeared on the wall of a CIO I know. As it does every year, in fact.
Lord Sugar is the central figure in the UK's version of TV show "The Apprentice". Of course, had my CIO friend worked in the U.S. then it may have been a poster of Donald Trump on that wall, in Ireland, it might have been Bill Cullen, in Brazil Roberto Justus ... but the slogan on the poster would have been the same ... "You're fired!" (OK, Roberto's would read 'Você está demitido!' but you get the picture).
Lord Sugar, like his global counterparts, is a very successful, (some would say) inspirational businessman but that is not the reason for the poster per se, nor is it that Lord Sugar's fortune was largely amassed in the tech industry which would be an obvious connection between him and my CIO friend, Max. It's the words on the poster that inspires him every January.
The turn of each new year is a time when Max, fires ... himself. And he does it in two ways that fascinate me.
You're Fired #1
Each January he imagines that he has been fired from his gig and is out of work, I mean he actually clears his desk and carries stuff out in a cardboard box! Then, he visualises seeing an advertisement for his job, he pictures himself applying and being invited for an interview. Finally, he envisages what he would say at that interview.
Try it yourself, imagine being interviewed for your job. What would you say? As an outsider, how would you feel about your IT team's strategies and how they align with business goals? What are the strengths and weaknesses of the leadership team? What would your USP be coming into your role afresh? What changes would you make? How could you improve methodologies? Where could you make efficiencies, where and how could you improve productivity?
Now, Max chooses January to do this because the Christmas and New Year holiday allows him enough distance from his job that he is able to take himself out of his role, but I reckon this is something that could be done at any time of the year - after a weekend or a holiday or vacation. If you are really imaginative you could probably even do it over a lunch break.
If you do it properly, Max believes that it can have a profound impact on your performance. You have to be honest, answer those questions above candidly. Sometimes the thing that needs to change is YOU, you have face harsh self-truths and that can be painful - who isn't at ease challenging someone else’s behaviour or thinking? Taking a deep breath and a step back to form a critical analysis of our own can be a wholly different prospect!
However, the more constructively you approach this, the greater the benefit.
Max says he emerges from the exercise reinvigorated and with a clear plan for the year ahead.
You're Fired #2
The second way Max fires himself is almost a natural by-product of the first. He fires himself from as many individual commitments and responsibilities as possible.
When he first started to do this exercise a few years ago he began to realise that there were huge chunks of his "to do" list that he just didn't need "to do". As a CIO he was meant to be a leader but there were times when he was more of a manager. For instance, there were tasks that he had not let go of, either because he didn't trust his team enough to delegate them or (being more honest) he just really used to enjoy doing these things back in the day when he was a Project Manager.
That second point is perhaps the most interesting. The problem Max found is that he had come to identify with the things that he had become super proficient at, then as he got rewarded financially and emotionally within the business for doing these things, the harder it became to separate from himself from them.
He makes a list of the things that he REALLY loves doing, the things he would derive the most instant satisfaction from and he delegates those tasks.
This leaves time free to tackle the really gritty issues - the ones that are the difference between success and EVEN greater success. Do you have issues like this? Issues that, if tackled, would have a massive positive impact but you just don't get round to them because of all the other stuff you have to do.
Letting go of something that seemingly gives you a sense of value is really hard and takes incredible self-awareness. Stepping out of these safety zones and stepping into the unknown, into totally new territories, tackling things that actually ... you may not be as good at ... that takes bravery! Here's the thing though, what Max found is that the satisfaction you get from conquering these tougher challenges is massively greater than the instant, ephemeral gratification of completing a task you could do with your eyes closed.
It was hard at first and not just for Max.
Project Managers had come to depend on Max, they were used to him either taking the reins altogether or at least being hands on enough to make operational level decisions. Some of them felt withdrawal symptoms. Over time though, his teams grew in confidence. They realised that decisions they may have waited for Max to make, they could make themselves, incrementally speeding up the project process as a consequence.
As individuals in the team became more self-confident something else interesting happened. They started to fire themselves too!
One by one they would come to Max and suggest that something that they or a colleague were working on could be better serviced by an outsourced provider and they backed it up by having taken the time to source a specific solution from the Project Management as a Service market or, more often, we'd have had a call asking for advice.
In conclusion, all of this takes great self-awareness and buckets of self-confidence. Letting go IS hard but the rewards are immense. Joshua Reeves, the CEO of Gusto, is perhaps the planet's best exponent of this. Reeves told The Wall Street Journal, “Wearing five different hats is not going to scale very quickly.” He is right.
Reeves told Quora that you should make time for introspection. "It’s incredibly easy to get caught up in the day-to-day routine and have life simply pass by," he says, "Choosing how to spend your time requires introspection – a time to think about what’s working and not working, what we like and don’t like, and then change how we spend our time."
"In school, there’s a semester or quarter system that catalyses this introspection. At the end of each semester, you need to think about which classes you liked or didn’t like, because that informs which classes you choose next. In life, there are no quarters or semesters unless you create them. This time for introspection can be weekly (i.e. by going to a favourite park every Sunday), quarterly, or even annually. Use whatever cycle makes sense for you. The main thing is having a structured, deliberate time where you take a step back and think about how you’re spending your time."
It’s becoming increasingly important for leaders to “fire” themselves from as many of their responsibilities as they can. In an IT Project team’s formative stages, it’s not unreasonable to expect a CIO to make or review every decision, write every job or role description, interview every candidate, negotiate every contract and while you're at it, put the kettle on! As IT Projects become more complex and IT and business strategies become more and more aligned, doing all these those things becomes, if not impossible, highly unrealistic.
In many instances though, it is difficult for leaders to let go ... so ... just like Max, start by ... letting yourself go. It’s been nice working with you.
Find out more about Project Management as a Service
wsj.com-CEO shadows workers to learn nitty-gritty details
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
Stoneseed's Professional Services Director David Cotgreave’s blog on one CIO’s strategy for greater effectiveness has been published on CIO.com. This blog explores the unconventional ways one CIO stays on his toes by firing himself and evaluating his position from an outsider’s point of view.
CIO is the leading information publication/ brand for today's busy chief information officer. CIO's publication addresses issues vital to the success of chief information officers worldwide. CIO.com provides technology and business leaders with analysis and insight on information technology trends and a keen understanding of IT's role in achieving business goals.
Read the full article
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