And you begin to ask – have we missed something?
The answer is almost certainly ‘yes’.
At Stoneseed, transition into service is an aspect of the project lifecycle that we are increasingly helping with clients with and this “reluctant customer” or “reluctant stakeholder” phenomenon is one that we are seeing repeated on a regular basis. It’s like getting to the edge of the penalty box and being afraid to shoot, procrastination at the delivery end of IT Projects is on the increase.
As a Project Leader, you have a number of options here. The most popular two are, as a project manager friend poetically calls them, the "Bulldozer” and “Butterfly" approaches.
She told me, "The bulldozer approach pretty much does what it says! You have other projects waiting, you've spent blood, sweat and tears on this project! Testing is going well, ok there are a few bugs, but you've delivered projects before and sorted niggles after the 'go live' day. So you use your persuasive skills to convince the client that it's just 'opening night nerves' and that the project needs go-live. NOW!"
The problem with this approach is that it's not win/win. OK, you got what you want, the project is signed off and transitioned into service but what about the end client? How do they feel? Bullied? Railroaded? And what about the end-users who have to put with buggy software? Are they happy?
And ultimately, what about your team? Can they really move on when they keep having to field support calls post-delivery?
Years ago, a wise IT Project leader once asked me, "If you deliver your project, and it doesn't bring the full impact to its users on day one, have you really delivered the project at all?"
So, what of the “butterfly” approach?
"The butterfly approach is altogether less heavy-handed. You've heard of taking a helicopter view, you can visualise exactly what's meant by that, so hold that thought. Swap the chopper for a delicate butterfly though. Same job, it takes an overview of the project from a high viewpoint but because it’s smaller and more delicate it can also really zoom in and check very specific parts of the project for issues that may have been missed. You'll have seen a butterfly land on the buddleias - imagine a helicopter doing that!! It would blow it everywhere! No, the butterfly gently lands on a single flower, does its job and leaves the rest of the plant unaffected. The attention that you give to your IT Project at this point in its lifecycle needs to be just as delicate, just as precise and just as non-destructive to everything else you've created."
So, let's park the bulldozer. How does the butterfly approach work with your reluctant customer?
"At this stage, the quality of the outcome is based upon the quality of your questions. The best project leaders direct this crucial conversation by only asking questions. It's a hard skill to learn because every sinew of you wants to get defensive and scream that you've delivered what's been asked of you! Stay calm and just ask questions AND take notes!"
Questions like ...
When they voice a worry ask, “What do you mean by that?” And after they've answered ... ask what they mean by THAT? (Drill down! Often the gold is in the answer to the third question).
What are their concerns? What would a solution to their concerns look and feel like? Who has expressed the concerns? When did the doubts start? (This can sometimes really help you pinpoint a specific time when confidence was lost and gives you a great target for that butterfly!)
Has something changed within the organisation? Is “regime change is in the air”? It happens with a cabinet reshuffle doesn't it, all the best-laid plans go out of the window as incoming Ministers seem to find new money for new initiatives. Businesses are the same, whether it is a promotion that opens up new possibilities, or mergers, acquisition, company sales etc, they all bring with them a large portion of uncertainty that can unsettle decision making.
How is your client contact and their end-user team feeling about their ability to use the project once it transitions into service? Get a sense for any doubts about end-user capability. Ask if there are post-delivery capacity issues. Do they trust the project's ability to deliver the business need? Do they trust their ability to make the project to deliver the business need? Can they handle this project if it were to go live now? Basically, there may not be a problem with the project, but you could spend weeks looking for one and fixing things that didn't need fixing when all that was needed was some extra staff training!
Often, when you take time to listen, REALLY listen, your end client will identify the thing that is missing for you and it can be something as simple as a requirement, a function or a report that can be easily accommodated. The key then is to agree on how to proceed. If it's an easy fix - do it! If it's something that you missed - admit the oversight and do it! If, on the other hand, it's a large piece of work that's needed, advise any extra costs, timeframes, etc. If it's an internal stakeholder, ask them to suggest which other business projects should be delayed to accommodate their new requests - actually take them to your whiteboard (or digital equivalent) and ask them to choose which other business manager's project should be delayed to extend theirs.
Prevention Is Better Than Cure
Most project teams start this process at such a late stage that it almost always causes delay. The trick is to unleash your butterflies regularly during the lifecycle so that you can spot possible issues and deal with them.
Also, maintain a culture that is receptive to feedback throughout. These days, IT Projects are more transparent than ever and most of the popular methodologies lend themselves to you being able to pop the bonnet once in a while to show your client how things are working. Have regular catchups and solicit feedback at key milestones or whenever is suitable. If you were painting someone’s house, you might just do a patch and then ask the homeowner what they think before climbing the ladder and attacking every wall with your paintbrush. Same with an IT Project - don't leave it till the job is finished to find out they no longer like pink!
So, the reluctant customer shouldn’t be seen as a frustration – see them as wanting to give valuable feedback (albeit late in the day). Listening to and acting on client concerns usually means that you deliver a better project, more in tune with the business need and that plays out well when seeking commissions and green lights in the future.
Of course, it's not, the message behind the slogan is valid all year round. It's just, you never hear the message at any other time.
Similarly, there was a flurry of activity and media attention around the EU's General Data Protection Regulation (GDPR) last year and rightly so. The consequences of being at the centre of a data breach, with a potential fine of 4% of turnover, meant most firms heard the message and acted to get their house in order.
Then GDPR Day came and passed and everyone stopped talking about it.
Until British Airways was told it faced a fine of £183m for a data breach in which customers’ credit card data was stolen.
GDPR got real then, didn't it?
Like those Christmas dogs, GDPR is for life and not just for that long-forgotten deadline day. A few friends have told me that they think that their firms have taken their eyes off the ball since last May and that IS a worry. The problem is - you might not know if you have let things slide until you get stung.
The bad guys are not operating at the level they were at when you addressed your GDPR responsibilities last spring. They are getting more and more sophisticated and so your systems and approach have to evolve to match them. To be clear, BA got hit by scammers at the top of their game, I mean, just imagine how much BA will have spent on data protection and how sure of their security controls they must have been. "Fort Knox," was how one security expert colleague had imagined them to be and I guess few would have disagreed.
I think that most people doubted that the Information Commissioner’s Office (ICO) would levy the maximum fine available to them. 4% of BA's annual turnover, rough calculation - that would have been a fine of about £500 million. That's a pretty unthinkable amount, especially given the fact that the highest fine before GDPR was half a million.
Indeed many thought that the level of security British Airways had and the speed with which they reported the breach would have meant a more lenient approach. GDPR stipulates that you have 72 hours to report a breach, three days, it took British Airways just one day to announce it had been compromised.
Ian Thornton-Trump, a cybersecurity expert was quoted by Forbes predicting a fine "in the £5 to 10 million range". Many observers thought even this may be on the heavy side, so when that £183m figure was announced the whole internet security and business community gave a collective gasp.
It's not just the fine, of course, a data breach brings claims for compensation from customers who might have suffered financial fraud as a result, and then there is the incalculable damage to reputation that a firm may suffer following a cyber-attack. Furthermore, in this case, BA was also threatened with a £500 million class-action lawsuit.
The high-profile cases, like BA, grab the headlines but it is another BA altogether that concerned CIOs that we’ve been talking to. Business Analysts became so sought after during the initial GDPR compliance preparations that firms were struggling to find them. Our sister company, Access Talent, the IT Project recruitment specialist, reported a surge in enquiries for this role post-GDPR too. As more businesses are needing BAs with regulatory experience to help create guiding principles on how their information is governed, hirers are increasingly toiling in vain to find business-facing talent to fill these roles. As a result, the Project Management as a Service market is doing a roaring trade in Business Analysts – this market should be your first port of call if you too are having difficulty finding BA talent to add to your staff headcount.
Another consequence of diverting attention and resources into projects initiated just to make firms GDPR compliant is that, often, something somewhere else in the portfolio has to suffer. Few project operations factored this in, few organisations had budgeted for extra resources, so it fell to the in-house IT team to do what in-house IT teams always do – they had to deal with it. This meant a lot of burning of candles at both ends which would have been OK for the short-term fixes that were being worked upon last May and June. Over a year later though, many firms still have longer term GDPR projects that are sapping resources needed elsewhere and strategic business change projects are falling behind or not delivering their full potential. The PMaaS market is geared up to help with this – you should ask your Project Management Services partner to take a look at your portfolio and recommend resources.
GDPR is having and will continue to have an impact on the efficiency of project teams. Based on the number of cases reported, attacks are trending upwards. By just August last year, the ICO revealed that data breach complaints were up 160% in the three months or so since GDPR had come into force.
Now, a year on from those figures, the ICO just published its Annual Report and it is clear that this was only the beginning. In this first Annual Report since GDPR took effect, the ICO reports complaints from the public almost doubled.
The ICO also reported a considerable increase in reports of data breaches that it received from companies, including 13,840 personal data breach reports under GDPR. This is more than four times the number received in 2017-18 and cybersecurity was cited as being at the root of many of these.
There is good news in the ICO’s Annual Report though, in more than one in eight (82%) of breaches, the reporting organisation had sufficient measures in place, or was taking appropriate steps to address the breach, that the ICO was not minded to take any further action. Furthermore, in fewer than 1% of cases, the ICO began proceedings beyond issuing recommendations or advising further action, and just 0.05% of cases resulted in financial penalty.
While it seems that UK businesses are over-reporting data breaches, the ICO states that this is a sign that organisations "are taking the requirements of the GDPR and DPA 2018 (Data Protection Act 2018) seriously" and, they say, "it is encouraging that these breaches are being proactively reported to us."
Less encouraging, but at the same time inevitable, is the increase in cyber attacks and the increasingly sophisticated tactics being used by the criminals but with just 0.05% of cases resulting in financial penalty, it’s not worth losing sleep over, right?
My old maths teacher had an interesting take on our perception of percentages, she would have said "0.05% is only a small number if you're part of the 99.05%. If you're part of the 0.05% it's ENORMOUS"
This is the take away from all of this! Take a regular walk with your German Shepherd guard dog around your perimeter fence to make sure that there no holes in your IT Projects and systems that these guys can exploit, and make sure that the measures that you have taken are not sapping energy from key business change initiatives.
Many of my friends are sharing a view that their firm walked the guard dog around the fence last May, but it has stayed in its kennel ever since.
Remember, that dog is for life! So is GDPR!
Agile. What Is It, When Should You Use It?
The story goes that seventeen software thought leaders, programmers and developers met at The Lodge at the Snowbird ski resort, in the Wasatch mountains of Utah. They skied, ate, and talked. What came out of those two February days would be ground breaking, the Agile ‘Software Development’ Manifesto would change project management - forever.
When thinking of the term agile you think of something that is faced paced and able to change direction in an instant, for example, a Manchester United footballer. The terms ‘faced paced’ and ‘change of direction’ are extremely applicable to Agile projects.
Agile projects move extremely quickly, the methodology allows you to work quickly in order to deliver new software to your clients on a faster or more regular basis. Agile projects don’t literally change directions, but teams do have to make decisions that can potentially change the course of their project, for example, when a particular issue must be solved quickly, Agile suits this environment to ensure that delivery isn’t delayed.
This is how I summed up Agile in an introductory, flyover piece on methodologies ...
Although Agile hasn't been around as long, it is now also considered one of the "old faithful" methodologies. Agile is one of the most popular Project Management approaches and for many PMs, it is their default.
When Is It Most Effective? Where it is advantageous to see incremental deliverables – e.g. software development or to “box” up elements of functionality, build it, review it and amend, or multiple streams at the same time. So, Agile benefits projects that are incremental, evolutionary or iterative and collaborative projects, requiring cross-departmental communication. Agile was created to address some of the perceived limitations of Waterfall and as such it is perfect for fast-moving environments where greater flexibility is key, the most obvious example being software development.
The "Manifesto for Agile Software Development" defines the ethos behind the methodology nicely, placing individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan. The 12 principles of Agile (more detail in the stand-alone post on Agile) leave users with clarity of purpose but lots of room for creative thinking.
What do advocates of the agile methodology say?
Continuous Delivery And Constant Visibility - Agile allows for a continuous stream to be delivered to your customer. Throughout the project, customers may be ‘drip-fed’ different iterations and incremental chunks, new versions of the software may be delivered continuously over a certain time frame, for example, once a week. With each delivery customers may be given a list that details the various features that have been added during the latest phase of the project.
More effective Short to Mid Term Planning - One of the main attributes of Agile is momentum, it allows a project to run fluidly through the various short-term phases of development. Issues may arise towards the end of a phase, rather than allowing this issue to delay completion developers can plan to resolve the issue in the following phase of the project, this, therefore, reduces the chance of delays whilst ensuring issues are resolved.
Ongoing Testing- Agile allows for modular testing to be carried out throughout a project. The Agile Manifesto states, “Working software is the primary measure of progress,” therefore ensuring any issues that arise throughout a project are addressed is vital. The agile methodology allows for testing to be carried out throughout the project and can, therefore, be rectified. This reduces the risk of issues de-railing a project towards the end.
Rapid Evaluation and Delivery - Agile can also allow your team to quickly produce a fully functioning piece of software in a shorter timescale. Evaluation is fast and actionable increasing the effectiveness of software development teams.
Flexibility And Better Change Management - Change can occur at many stages during a project, whether during planning or during a certain phase of the project and while some consider change as a problem, Agile allows change to happen in small manageable chunks. Smaller changes can also be easily reversed (in comparison with larger changes or when using other methodologies). If the change is not suitable to the project, Agile facilitates quick restoration of previous iterations or for a new, more acceptable change to be made. Overall, these factors ensure that individuals start to see change as a positive rather than a negative.
What Do Its Detractors Say?
Need For Cultural Change - The demands in which Agile teams are placed under are in stark contrast to various other methodologies, this can be an issue for those used to alternative approaches. Agile requires teams to work closely aside one another in a disciplined manner. Teams that are not used to these demands can struggle with this and often a cultural re-frame is needed. In order to counter this, in-experienced teams could be mentored, enabling them to cope with the demands of Agile, whilst also learning the necessary skills.
Need For New Skills - In order for Agile to be successful teams need to possess a set of advanced skills. This is again a key issue for inexperienced teams who may not yet have developed those skills. Teams need to be able to work quickly in a pressurised environment whilst having the capacity to solve complex issues. In order to work effectively within these environments, teamwork led skills, such as communication, are vital to ensure the team works as a collaborative unit. Again, inexperienced teams can be mentored.
Need For Extra Training - Ensuring teams are adequately trained is vital for Agile project success, many detractors point to the fact that insufficient training can lead to an increased risk of failure compared with other methodologies. This is true but could be said of anything, lack of driver training could result in more car accidents but that doesn’t mean you should abandon the car – you stick on the ‘L’ plates and learn. Those that are used to other methodologies often assume that the rules are more relaxed on an agile programme due to the decreased reliance on other development processes. This is however not the case, teams must follow the tasks that are prescribed to them in order to ensure their project is a success.
Clarity Can Be An Issue - Agile is extremely dependent on the clarity given by the client. When a client is clear in terms of their intended outcome your team will have a clear goal to work towards. However, when a client is less clear agile projects may go off at a tangent quicker than other methodologies, if left unchecked. Again, this can be solved by ensuring that your team has experienced members! Experienced individuals will know when further consultation is needed to fully understand the client’s desired outcome and expectations. These consultations gift you the chance to ask any potential questions whilst also gaining feedback from the client and should be carried out at each phase of the programme. Do this and an agile project will remain on track in terms of reaching your client's desired outcome.
There’s Danger of Excessive Risk-Taking - Agile's detractors believe that within inexperienced teams there is a risk of trying to complete too many tasks within one phase of the project, therefore placing an increased amount of pressure on the team. We have all seen over-ambition fuelled by the apparent simplicity and organisation of Agile processes and this is another area where experience is key in Agile teams. Experience teaches you what your limits are and the discipline to plan each phase accordingly.
In conclusion, on balance, I think Agile is the methodology most suited to most project types and probably the best foundation for a hybrid approach. Agile comes with more demands but with proper training and execution, the rewards can be much greater.
For context, I am writing this on the Wednesday after England's Cricket World Cup win at Lords and Novak Djokovic's Men's Singles victory at Wimbledon. Both the New Zealand cricket team and Roger Federer must have been able to feel their respective trophies in their hands but their opponents had that little added ingredient, more than luck, there was a tenacity, a drive, a never say die strength that, if you could bottle it, would make you a millionaire.
As a cricket fan, it has taken me this long to process what I saw on Sunday. The match had ended in a tie which led to a tie-breaker, which also ended in a tie all leading to a super over that delivered a frenetic end to a match that had sauntered along in slow motion until the last hour. It felt just like a lot of IT projects that I've seen teeter on the brink over the years - as convoluted, as exciting, as frustrating, as nerve-jangling, as unpredictable and, ultimately, as satisfactory.
Eoin Morgan's England team were predicted to take this tournament by the scruff of the neck, they were described by one pundit as "the demolition men" who destroyed teams in their wake, notching up huge totals along the way. Ahead of the final thought, I knew, in my heart of hearts, that it wasn't going to be easy. As a cricket fan, you know it never is with England, just like IT Projects are never easy. I just didn't realise it was going to be as hard as it was, a sentiment that many IT Project Managers can also relate to.
On the same day, across London at SW19, after almost five hours on court and over 400 points of tennis, the men’s singles final at Wimbledon was decided by a first-to-seven-point tiebreak. Roger Federer, now 37 years old, an eight-time Wimbledon champion, out-played Novak Djokovic for much of the match. Federer hit more aces, he won more points and he broke serve more often. Djokovic showed why he is the top-ranked male player though, he dug deep. In the 16th game of the final set, Djokovic executed his game better when it mattered and dominated the tiebreak climax to secure his 16th major title. Phew!
So, what's this got to do with IT Project Management?
It's simply this. While it's quite right that the likes of Djokovic, Stokes and Morgan get their adulation, for IT Project teams, long days that make you ache from head to toe are a normal occurrence. It's what we can learn about endurance, resilience and teamwork that could help you win with your next IT Project.
1 - Strong Leadership
England captain Eoin Morgan demonstrated his leadership skills, not just during the match, but apparently, also at a reception thrown by the Prime Minister at 10 Downing Street. The team were a little rowdy, chanting "Allez Allez Allez" when Morgan intervened and said, "Look, guys, we’ve got to calm it," according to reports in the Daily Telegraph. They calmed it. Firm leadership and respect from the team for that leadership are vital and sadly missing in many of the IT Projects we are asked to help bring back into line.
2 - Deliver When It Matters
A lot of struggling projects have a lack of clear prioritisation. Look at that Wimbledon final, Federer hit more aces, he won more points and broke serve more often but it was Djokovic who executed his game better when it mattered. Be mindful of what really matters in your IT Project and focus your A-game on those areas.
3 - Consistency
Djokovic, Federer and Rafael Nadal, who fell to Federer in the semi-finals at Wimbledon, have an unprecedented stranglehold on men’s tennis. Federer is 37, Nadal is 33, Djokovic is 32. The greatest male tennis player of my childhood, Bjorn Borg retired at 26. None of today's "veterans" are playing their very best tennis these days, but all are playing with a steady consistency that is keeping the newcomers out of the top rankings.
This consistency is something we should aim for. All too often I see the same project team deliver a resounding success and then follow it with a turkey. Be a student and practitioner of what works for you!
4 - Use External Resources
Coaching obviously played a huge part in both the sporting successes outlined here and your IT Project partner can be a really useful independent pair of eyes when you can't see what's going wrong with your IT Project.
Beyond this, it's worth developing a sense of flexibility about who makes up your IT Project team. Don't feel that you have to rely on your in-house squad when there are a range of resourcing solutions available from the Project management as a Service market. One Project leader told me once that she feels like they have failed if they have to reach out to PMaaS and this way of thinking needs a reframe. Traditionally, the England team would have all been born in this country, a casual glance at Sunday's heroes reveals a different story! Captain Eoin Morgan was born in Dublin, Jofra Archer in Barbados, Jason Roy in South Africa, even man of the match Ben Stokes was born in New Zealand - you get my point! You don't have to rely on 'home-grown' talent for your success.
5 - Celebrate and Remember It's Fun
Watching Djokovic during his game (and Federer too) was a lesson in celebrating each point. I mean, they don't run around the court in a lap of honour at the end of each game but there is always a self-congratulatory 'air fist' or a growled "YES". No little victory goes unacknowledged and it should be the case with IT Projects. We're really good at chunking work into manageable units, like sets and games in tennis, but we are often really bad at giving ourselves credit where credit is due.
I got really tense watching the cricket, I paced around, I chugged a beer or two, I bit my fingernails and then I remembered that I loved cricket and that this was meant to be fun. We sometimes forget to enjoy ourselves when delivering IT Projects too. C'mon! This is the best job in the world - let’s remember to enjoy it!!
6 - Stay Calm
I recall Stokes and Butler coming out to bat to a tumultuous Lord's roar! They stayed calm hitting two boundaries on their way to posting 15-0 from their six balls. Under such pressure how easy would it be to lose your head? Under the scrutiny of the c-suite, the clamour for transparency from stakeholders, the pressure for successful delivery, how easy is it for us to lose ours?
I remember, early in my career, a project manager having a full-on nervous breakdown over his IT project, I vowed then that none of this was worth shortening your life for. Panic makes terrible choices!
So that's it really! It's all about having that special something extra in your locker. Stokes has it. Djokovic has it. Morgan has it. YOU TOTALLY HAVE IT!
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.
The reason for such opulence at the start of the week is that, at Stoneseed, we are celebrating our tenth anniversary.
The tech world was a very different place 10 years ago!
A decade ago, there was no 4G! There was no Slack!! No Pinterest!!! No Instagram!!!! How we survived is beyond me!
The IT Project Management world has changed beyond recognition too.
Ten years ago, a handful of firms had started to promote IT from business technology support to a strategic business partner but, for most, IT was still a back office function. That's not to say that the projects weren't complex and essential, they totally were. The thinking though, for many, was "this is what we want the business to do, how can IT help achieve this?" whereas the thinking now is more "what can IT achieve for the business?"
On paper, there's a hair's breadth between these concepts, but in reality, they are miles apart. Over the last decade, IT Projects have evolved from supporting business change to facilitating it - and now IT Projects are driving business change.
As IT Projects have become more complex and more business case led, in turn, the teams managing them have had to up their game too. I'd like to think that all of us would be amazed at how much more sophisticated and professional we are compared to our 'decade ago' selves. The quantity and quality of our work have grown to match demand and although we're largely all still using the same methodologies our understanding of what they can do for us has developed. Hybrid methodologies are increasingly the norm, where IT Project teams have the confidence and creativity to use different methodologies to deliver individual parts of a project, resulting in faster and more efficient delivery.
As business has asked more complex questions of IT, we have found a seemingly never-ending stream of great answers. IT Project in-house teams have matured and evolved and the Project Management as a Service universe is expanding exponentially like any universe should! In fact, I believe that the PMaaS market has a solution for every business challenge your IT Project team will ever be tasked with solving - and this isn't the Champagne talking - it's a hypothesis that I and my colleagues have tested time and again.
Our mindsets have changed too. Ten years ago, IT Project Managers were still fairly reactive to business need. These days, most PMs that I work with are proactive, they anticipate business need and prepare their teams to deliver change, and it is change that they themselves have often identified is needed. As a result, many IT Project teams have been elevated in terms of perception from cost centre to revenue generator - now that is REALLY exciting.
So what about the next ten years? How different will the tech and IT Project Management world look by 2029? How much of an impact will AI and machine learning have had? How different will the workplace look? Will BYOD (Bring Your Own Device) be a quaint memory as everyone works remotely and hence has nowhere to bring their device to? Probably, like you, I have my own theories on how things will unfold but, as I hear another bottle of fizz being opened, it would be terribly rude of me not to join my wonderful colleagues.
Suffice it to say ... however the next decade unfolds, whatever challenges your business goals will throw our way, we will be there to meet them. Your IT Project team, the Project Management as a Service universe and Stoneseed, your partner in IT-driven growth are ready, so bring it on!!!
Before I sign off, you can't have a party without party games so here's a quick birthday treat in the shape of a quiz! It illustrates how the tech landscape has changed over the last decade!
QUIZ| Five Tech Giants That Weren't Even A Thing When Stoneseed Was Born
1) Created in October 2010 what app was Apple's iPhone app of the year in 2011 and bought by Facebook CEO Mark Zuckerberg for $1 billion in April 2012?
2) What first launched on the App Store in the summer of 2011 as Pictaboo, but still with Ghostface Chillah as it's logo?
3) What did Steve Jobs describe as "the best browsing experience you'll ever have" when he launched it in 2010?
4) What workplace app did Stewart Butterfield first start working on in 2012, originally as a web-based multiplayer game?
5) What IT Project Management and Services company was founded in 2009 on the belief that conventional IT Services organisations had become too vendor focused and what clients really needed were strategies built on objective technology decisions delivered by talented people at a fair price?
The answers are at the bottom. As I write this I am raising a glass to the last ten years and another to the next decade. One thing I do know, new business IT Project challenges will continue to evolve and I for one cannot wait to meet them all head on!
1) Instagram 2) Snapchat 3) iPad 4) Slack 5) Stoneseed]]>
Fast forward six months, it's a different story. The shine has worn off, the customer is unhappy, and the previously stable system is now the most hated application in the department.
What happened? Because this does happen!
In most cases where IT Projects go from hero to zero soon after delivery, it is because of a lack of adequate support.
“Each time a query has to be raised the support desk simply do not know what to do with the application and tickets remained unresolved – they don’t who to call!” This is actual feedback I read on an IT project just five months after delivery. End users were forced to create elaborate workarounds. Confidence was lost.
This is how reputations are ruined.
Organisations support their applications differently and IT project teams can address this by reframing the post-delivery landscape and working on the basics of a support service. So, for how long should you support your project?
I remember once, during onboarding, a former colleague asking new recruits, "When do YOU think our responsibility for an IT Project ends?"
The ink would hardly be dry on their freshly minted certificates and the theory would be fresh in their head so almost all would answer that responsibility ended on, or shortly after, delivery.
My colleague would mimic that sound the Mr Babbage computer emitted on Family Fortunes when a contestant gave a wrong answer.
Some would then consider that responsibility might last into a settling in period, or perhaps until customer or end-user training was completed. Again, my colleague would make that iconic television show sound and then smile.
"It never ends," he'd say, adding, "we are responsible for our IT Projects until the day they are superseded."
His thinking was that as long as the application was live, those responsible for developing it should be available to answer questions about it. To be clear, he wasn't advocating 24-7 support or calls from a client at 10 pm on a Sunday night, but he was adamant that having unleashed a solution onto the world, we should at least be answerable for its future behaviour.
Whether it is the handy person fixing the printer, super users you've trained up or an outsourced support desk, all will eventually have one central question: if I can’t work out what to do, who do I call? Who do you think your IT Project end users should be calling? Ghostbusters?
The next question, after who will help, is usually how quickly will they help me? This can become a nice metric by which to be measured. In my experience, most issues can be resolved really quickly and teams that have processes in place to accommodate support questions can quickly raise their profile and become organisational heroes. As long as it doesn’t derail the daily tasks!
IT Projects are our babies, and while some us feel an ongoing instinct to support them, many IT Project teams shut the door once they have flown the nest. It's understandable because, to be fair, there never seem to be enough hours in the day for the work you have scheduled let alone an old project coming back to haunt you.
However, being there in a support capacity builds great relationships.
The thing is, you never know when you might need the good will that you bank by being the one to call upon in a crisis. Your next project may hit some roadblocks and when you need stakeholders to cut you some slack, they are more likely to do so if they remember how grateful they were that you were there in their hour of need.
The third question, asked by end users, is likely to be ‘who else needs to know that we are in a pickle?’
Who does need to know? Put yourself in your end user’s position. They can't do their job one day or their productivity is reduced because of YOUR IT Project, they won't hide this and hope no-one notices - they'll tell their boss. Now put yourself in the boss's shoes. She oversees a team of end users and their IT issues are denting her department's targets - what does she do? When IT isn't performing it quickly shows up on board level radars.
IT is at the strategic heart of business now and with this increased prominence comes increased responsibility. Many are arguing that the lifecycle of a project, that once spanned from initiation to delivery, now extends into the operational period. It is here, when end users are manifesting your project's business value, that they need your support more than ever.
Finally, here's an exciting thought. One of my project manager friends has identified this as a whole new service offer. "Like offering an extended warranty on a toaster," he told me. Extended warranties always come at a premium and he has managed to negotiate extra budget for his team to provide ongoing support beyond what would have previously been expected of his team. Rather than seeing support as a problem or a distraction from his schedule he has creatively negotiated new budget for the IT Project team.
Extra money! Now that's something worth your support!
I’d love to hear your thoughts on this, please get in touch – how far are you willing and able to support your IT Projects.
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.
As IT Projects have got more complex, teams have started to fall into the trap of over-complicating their approach to managing them. Where's Marie Kondo when you need her?
If you haven't heard of Marie Kondo, she is a Japanese tidying guru. In her Netflix programme, she promises that her "KonMari" method will deliver, not only a de-cluttered house but also a clean and de-cluttered mind. I wondered whether this was something we needed in IT Project Management.
So where to start?
1 - Declutter the docs
Have you ever heard a Project Manager complain that they completed a document during a project, then picked up another and found themselves writing or even copy and pasting the same information? They'll say that it slows down productivity and adds little benefit. It’s time to declutter your docs!
Let's drill down a bit on this because Marie Kondo's method of decluttering really works here.
Faced with IT Project docs, she'd say:
iii) Be appreciative. Appreciate the work that went into the creation of a document. Chances are the person next to you spent hours creating drop-down lists in it two years ago.
2 - Inbox zero
"Inbox Zero" is an email management system that means you end each workday with no emails in your main inbox - not even read ones!! Imagine – relaxing just thinking about it, isn’t it! The peace of mind that comes from having rigorously and effectively sorted, actioned, deleted or forwarded every message that pinged during the day is priceless.
It might seem like a crazy, unachievable dream! If you have hundreds (or even thousands) of unread emails, it can start to weigh upon your mind and impact performance. Colleagues who have achieved this inbox nirvana swear by it. The positive effect on their mental health transfers into every aspect of their life. On told me, "You don't wake in the night worried that you may have missed something.”
3 - Have the stuff you use every day close to hand
When decluttering a kitchen, Marie Kondo will recommend that you put the plates you use every day in a cupboard that is easy to get to, meanwhile, that ice-cream maker can probably get stored in a less easy to reach space (we have a cupboard of regret!).
It's the same with IT Projects. We often ask Project Managers on struggling IT Projects to show us how they access the crucial system documents that they use to run their projects. In our experience, few are just one click away from the assets that are the lifeblood of their projects.
"If you have to click the start menu and scroll through your programmes, you're starting your task too late," one PM friend says. "The programmes and documents that you use to run your project should be as accessible as the knives and forks in your kitchen.”
The more successful Project Managers have links to the stuff they use every day on their desktop or pinned to the taskbar and on the first page of apps on their phone!
And this doesn't have to be all work, work, work - if your motivational music comes from Spotify playlist each day - stick that on your taskbar too!!!
That's just three areas that could be de-cluttered. I'm sure there are more. This week take a look at your portfolio, work out what you NEED to manage projects, like we did with Stoneseed's induction pack which consists of the Project initiation document, RADICAL log, Weekly Update, Change Control and Project Plan. Take a look at how your Project Management Office could help streamline document suits.
Ask yourself, honestly, if your working environment and approach could use the Marie Kondo touch.
The previous two volumes we published of Straight Talk on Project Management by David Cotgreave, have proved so successful that we decided to do VOLUME III.
Since the last volume, David has continued to enlighten us with his in-depth knowledge of Programme & Project Management and the issues that can arise during Project Delivery.
So, if you’re looking for a great holiday read this summer, get your FREE copy here.]]>
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.
"What's going wrong?"
Both these questions were asked by different Project Managers leading IT Projects that were failing this year. Both had identified issues, both were keen to sort those issues out, both held almost identical team meetings to address the challenges.
One was more successful than the other.
The first Project Manager, who framed the question in terms of looking for improvements, was the more successful of the two.
They are both seeking the same outcome, the question is essentially the same - let's identify what isn't working and make it work! So why did they get different results?
I believe that it is down to the wording of the question. Look at how the second question focusses on the failures. Sure, identifying that your issue is scope creep will prompt you to sort out your scope creep, but not before the team has beaten itself up over the fact that you have failed to keep control of your scope. Shining a bright light on the problem rather than what you can do to avoid similar banana skins in the future can limit your potential.
The first question is much more positive. You may have scope creep issues but, by asking the question this way, you immediately open up a solution space. The answer is more likely to be that you'll say 'no' to scope changes or, at least, set up robust mechanisms for reviewing requests and communicating expected consequences to stakeholders.
And yet, the more negative question style is more common in debriefs after failed IT Projects and so teams may not be getting the best out of this time investment.
How you talk to yourself is very important! But where does all this negativity come from? Are we programmed this way?
In his book, What To Say When You Talk To Yourself", Shad Helmstetter talks of the 148,000 "No's" that you will most likely have heard before your 18th birthday. Whether it's your parents trying to protect you or your teacher or community leaders trying to keep you heading in the right direction, you heard "no" a lot as you were growing up. Compare that to the number of times you were told how much you could achieve, what you could accomplish and it's easy to understand how these negative thought and language patterns dominate. Helmstetter claims that "leading behavioural researchers have told us that as much as seventy-five per cent of everything we think is negative, counterproductive, and works against us."
So, it is in our programming! But here's the thing. We work in IT, if anyone should be great at reprogramming, it is US!
You'll have heard of NLP.
NLP, short for neuro-linguistic programming, can be used for personal development, phobias, and anxiety. NLP uses perceptual, behavioural, and communication techniques to make it easier for you to change your thoughts and actions. Many successful sports coaches, world champions, swear by it! My Project Manager friend Karen does too!
"NLP will help you map out your view of the world, and because they will be different, understand the maps of others. NLP can help you to understand the programming behind your thought processes. It makes you more self-aware," she wrote to me recently.
Self-awareness may be the key.
The author of NLP for Project Managers: Make Things Happen with Neuro-Linguistic Programming, Dr Peter Parkes, carried out a poll and self-awareness was the number one behaviour trait that stakeholders wished that their Project Managers had. Karen says, "If you're not self-aware if you don't understand yourself, what makes you tick, then how can you even hope to understand and motivate your team."
Since finding NLP, Karen believes that communicating with and motivating her team has vastly improved. "NLP taught me that our world view will be dominated by our senses, in an IT Project, we will either see, hear or feel a problem, for example. If you listen to your team, really listen to the language they use and reflect their world view in your communications - you open up a new level of trust and understanding. I have a team member who will say, 'I don't like the look of this.' Another might say 'This doesn't feel right,' and another will express disbelief at what they are ‘hearing’ - but they might all be describing the same issue. In NLP these preferences are referred to as “Visual”, “Auditory”, and “Kinesthetic”. If you choose the wrong language your communication might not be as effective. Saying 'let's see what our best options are' to a team member with auditory preference might not hit the target as well as 'which of these options sounds best' - it sounds daft, but it works!"
Another of my Project Manager friends, Stefan has a team driven by feelings, they are all “kinesthetic”. Stefan has a "How It Will Feel When It's Done" list. Now, you may have a "To-Do Today" schedule or a "Task List" - how inspiring are they? Stefan identified that a cold list of "stuff" that needed doing didn't excite him or his team, tasks were met with little enthusiasm and often milestones would either be completed only just on time or late.
"The problem was how we were presenting our own workload to ourselves; it was dull and left us flat. So we started to think how we would feel when each task had been completed. Attaching a positive feeling to even the most mundane task suddenly made it a worthy mission. We'd be excited! If another team was depending our task delivering on time, we'd imagine their gratitude, we'd visualise the business change that our work was about to facilitate, imagine the end user experience that we were enhancing."
Another project team I worked with last year has banned 'need to', 'have to' and 'must do' from their language. Carl, the PM, told me, "Expressing tasks in this way makes them chores! You need to clean the bathroom, or you must do the hoovering! Doesn't get you revved up, does it? When approaching our tasks 'we want to' do them. Especially in the more grey performance/monitoring stage of a project and the more difficult project close phase, it's amazing the difference that 'wanting to' rather than 'having to' makes!"
How you talk to yourself is so important! That little voice is running a commentary on your life all the time. It is influencing your thinking and creating outcomes for your IT Project, usually without you even knowing. It's like having a coach in your ear all the time. Try to catch and correct yourself when negative language patterns dominate your communications.
So, in conclusion, mind your language!
AND get in touch! How can we make things better in your IT Project World?
What To Say When You Talk To Yourself – Shad Helmsetter, Grindle Press 1986
NLP for Project Managers: Make Things Happen with Neuro-Linguistic Programming - Peter Parkes, BCS (11 Mar. 2011)
This is one of my favourite bits of client feedback! It refers to a particularly successful deployment of Project Management as a Service resources.
The email as a whole talks about the effectiveness of the talent, the extra experience and skills that they provided, and how the project would have failed without them. What I really love about it though, is the notion that the project talent "fitted in" thanks to luck, rather than through intentional and meticulous research, assessment, reflection and positioning.
It reminds me of the scene in "The Devil Wears Prada" where Anne Hathaway's Andy sniggers at the Runway team agonising over very similar items. Miranda Priestley delivers a withering monologue about Andy's "lumpy blue sweater" and the concerted efforts behind how it came to be in Andy's closet ... Oscar de la Renta's "collection of cerulean gowns", Yves Saint Laurent's "cerulean military jackets" and eight other designers quickly using cerulean in their collections before, finally, it "filtered down through the department stores and then trickled on down into some tragic Casual Corner where you, no doubt, fished it out of some clearance bin." Ouch!
As Streep says, "That blue represents millions of dollars and countless jobs and its sort of comical how you think that you've made a choice that exempts you from the fashion industry when, in fact, you're wearing a sweater that was selected for you by the people in this room from a pile of stuff."
In the same way, placement of "cultural fit" Project Management as a Service talent should never be down to serendipity. Cultural fit should never be a happy accident. It should be an intended and stated outcome. Talent should be "selected for YOU by the people in this room." It certainly is with Stoneseed and I hope that other PMaaS providers are the same!
Consider this from stoneseed.com, "Project Management as a Service (PMaaS) provides access to project professionals, resources and tools at a flexible and predictable cost. Our services portfolio offers a true end to end service, from IT Advisory, through Programme & Project Delivery to Service Delivery. PMaaS provides access to Flexible Resources on Demand, Project Management Office, Process and Methodology, Tool Sets and a straightforward Cost Model."
Everything in this elevator pitch for PMaaS is vital to the success of your project and your business and at the heart of it all – people. None of this can deliver best results without careful matching of these people with yours and that means knowing your culture.
Writing for projecttimes.com, Paul Oppong says, "Project Management as a Service is not without its risks. Unlike some other “as a service” offerings such as Software as a Service and Platform as a Service, with PMaaS you are buying in the help of people. While people may be very effective project managers, they may not necessarily be a good cultural fit for the organisation ... people working within the culture already are likely to have a better idea of the “way things work around here” and how to get things done. With this in mind, in some cases, it might very well be preferable to gain the required project management competencies in-house."
Paul's article raises some good points and is worth a read but it misses a couple of points:
1 - Organisations using PMaaS do so usually because the competencies they need are not available in-house;
2 - PMaaS partners worth working with prioritise cultural fit. They won't compromise. Cultural 'bad fit' and even 'close fit' talent won't deliver your organisation's maximum required outcomes - so what's the point of bothering?
How do we do it?
First, we get to know you. I mean, really get to know you: your organisation; your industry; your unique story; and how YOU do business. We assess your needs; your in-house capabilities and we identify your capability gaps. Secondly, after careful consideration, we prescribe tailor-made solutions to your specific requirements. YOUR culture is at the heart of that process.
Every business has its own DNA. How you do business might be very different to how your competitor across town operates. Same business - different approach. That's your USP. Your culture and your ethos are key elements of this and should be respected and reflected in everything you do - including PMaaS.
Similarly, every Project Manager has their own unique way of delivering 'standard' working practices. The same PRINCE2 certificates can hang on the walls of two PMs and mean completely different things to them both. How one operates might dovetail beautifully with your DNA whereas the other might jar with it like fingernails down a chalkboard.
Marrying the two together – that is when the magic happens! Why settle for anything less than magic!?
Culture matters. The effects of a cultural bad fit last long beyond a person's time with you - weeks, months, even years! As a CIO friend once put it, "A single bad egg ruins the cake." We are very mindful of this and take rigorous care to ensure that every PMaaS placement is in harmony with the culture and values of the client.
These days, more than ever, IT Projects deliver business goals. For PMaaS to deliver the necessary return on investment it has to be delivered through a partnership between you and your provider. The key to a successful partnership? Your provider has to understand your culture and deliver in sympathy with it. On this, just like Meryl Streep's Miranda, refuse to compromise!
'&' or the ampersand is often misused and misunderstood. Largely thanks to social media communications, where you are limited to a maximum number of characters, this misuse is fast becoming something of a trend.
Again, so what?
I asked ten IT Project people to share what they knew of ampersand. One nailed it, eight out of the ten said it was short for 'and' - and one hilariously answered, "Isn't it in Norfolk?" I think (hope) that he was joking. Although to be fair, Ampersand does sound like somewhere you'd take the kids crabbing on the North Norfolk coast!
Is it a worry that nine people I asked didn’t know that usage rules exist? I mean, if nine intelligent people surveyed don't know the rules, then surely that means that 90% of readers won't know either so they won't notice. Surely?
Hmmmmmm. Maybe not.
To Susan, a CIO friend, "ampersand abuse" is a pet hate and a real nails down the chalkboard issue.
Susan wrote to me recently, "If you wrote up project documentation and substituted ‘and’ with 'n', as in rock 'n' roll, you'd have no credibility at all! To me '&' is the same."
When put like this, you do wonder why project managers take the short way out? What’s wrong with writing “and” - if "and" is what you mean?
"If a project manager can’t write a document correctly, what else are they doing to take the easy way out," added Susan.
The first thing about ampersand is that it doesn't necessarily mean 'and'. Here's a handy dictionary-style definition.
Ampersand: a stylized, contractual form of the Latin word "et". Although the Latin word "et" does mean "and", it is improper to substitute "&" for "and".
Many people incorrectly substitute this symbol for the English word "and".
Ok, but again, SO WHAT?
Here's why I think it does matter.
1 - It's a short cut. As IT Project Managers, a big part of our job is to find short cuts to expediate delivery or reduce costs. It is important, I think, that we convey the impression that we know which short cuts to take and when. Do pages of misused '&'s do this? I'm not sure it does.
2 - Another huge part of what we do is methodology. The CEO, the Finance Director, the whole board at most companies that I have dealt with do not understand the rules of Agile or Waterfall or any IT Project methodology that you care to mention. When greenlighting a project, however, they are saying that they trust that you DO. If your CEO knows how (and when) to use '&' and you have used wrongly it 40 times in a project proposal, they may ask what else are you bluffing knowledge of. It sounds daft but perception is reality.
3 - Our documentation matters! Grammar experts say that '&' should not be used except for in the most informal of communications. A project initiation document is among the most important documents to the success of an IT Project. Anything that creates an impression that it is not should be avoided. Susan the CIO asks, "Would you type a PID in the 'mistral' font or 'windings'? Would you sketch it out in crayon? Of course not, it commands your best presentation skills - take some pride!"
4 - It's a trend! Why follow a trend, if you don’t understand it? I was in a meeting last week where a forty-something-year-old project manager said, "Awse!" It was short for awesome. There was a tangible sense of cringe about the room, even the PM himself looked uncomfortable. Apparently, it's a trend! Doesn't make it right! To put this in perspective, these are fashion trends for 2019: 50s and 60s era couture gowns reworked shorter; volume dresses; corsages; ostrich feathers; front-loaded tool belts slung across the body; and nineties style acid and light-wash denim. Do you understand these trends? Will you be wearing them? So why follow the '&' overuse trend? (Although the light wash denim sounds cool.)
5 - It may also dilute your message. My copywriter friend Gareth was on a course once where the lecturer stated that in a list, a final item that follows the word ‘and’ is more likely to be digested by the reader than one that follows ‘&’. It’s something to do with the reader being hardwired to take pause when faced with ‘and’, whereas the attention zooms on and over the ‘&’.
6 - Finally, remember I said that out of ten IT Project Management professionals, only one nailed the rules of the ampersand? Yeah, about that, Martina is from Slovakia. Come on people! We need to pull our grammatical socks up!
This may be a tongue in cheek rant or I may be the self-styled grammar police and mean every word of it. I'll leave that for you to decide (by the way, my colleagues need not reply).
The point is though, that attention to detail has NEVER been more important. Your organisation needs a decent return on investment and you need to maintain high levels of successful project outcomes to get the next green light. Therefore, we all need to get every aspect of IT Project delivery right.
It's come around quick, hasn't it? One of my accountant friends drily commented the other day, "It doesn't seem like two minutes since we took down the IR35 decorations!"
The use of contractors in IT Project Management has greatly increased over recent years. With good reason, many businesses see contractors as a way to quickly hire the specialist IT skills that they need, without having to commit to a permanent hire. It can be justifiably argued, that operating in this way has given businesses greater agility to respond to the market needs of the present, and innovate to meet the market needs of the future.
This has not escaped the attention of the HMRC though.
After, in the view of the taxman, a highly effective rinse of the practice in the Public Sector, eyes turned to the Private Sector where the cost of a disguised employment to the treasury was projected to increase from £700 million in 2017/18 to £1.2 billion in 2022/23.
Which is how we find ourselves where we are - however many days, weeks or months away form IR35 day we are when you read this.
Those three words are key - "where we are".
I think acknowledging where you are is the most important thing that you can do right now.
I have spoken with employers who are 100% ready and I have spoken with those are 100% not. I have talked with those that know they have to do something and those that have buried their head in the sand. Some have a clear road map; others have a roughly sketched plan. Some could go on Mastermind and answer questions on IR35 as their "Specialist Chosen Subject" and at the opposite end of the scale we have heard one "what's IR35?"
It is a very broad spectrum. Everyone is on their own journey (and working at their own pace), but the inevitability is that we must all arrive together. The important bit is accepting where you are on the map and then taking the next step.
You'll have seen those maps at the shopping mall or the theme park or the zoo. There's always this huge, confusing expanse of stores, rides or animals and a very big arrow with a very simple message - YOU ARE HERE. If you want to get to the handbag shop, the big dipper or the elephants, knowing where you are in relation to them is key to planning your journey. So, it is with IR35, knowing and accepting where you are is vital to plotting your journey to April 2020.
Knowing where you are, allows you to calmly assess your options. Do you bring your contractors in-house and add them to your payroll? Do you absorb costs associated with IR35, or have an awkward conversation with your clients? Or do you completely re-frame your thinking on project resourcing and consider way to eliminate 'disguised' employment altogether, resourcing through Stoneseed's Project Management as a Service (PMaaS), for example, where our people are on our payroll and where IR35 is essentially de-scoped.
I'm writing this in April 2019, but you could be reading it in July, December or even closer to the deadline in 2020! And it almost doesn't matter - as long as you accept that YOU ARE HERE and work from there.
We have put together a calendar which will help you with resource planning for IR35. This is based on our experience helping organisations transition their resourcing models and feedback received by both Stoneseed and our sister company, Access Talent (the IT Project Management Recruitment Specialists). You can find the calendar here
Summer 2019 will be remembered, as much for the heatwaves, barbecues and paddling pools as for gauging current work forces, resourcing chains and tax liabilities. By the end of July 2019, I'd say that you need to have a robust understanding of your current work force, crucial contract roles and also have a strong sense for how rate increases may affect you. You should have started planning new processes or investigated alternative resourcing channels like PMaaS, where IR35 becomes irrelevant. Summer would be a good time to have started stakeholder conversations too, so that there are no unexpected surprises.
By November, hopefully, the only fireworks will be the ones marking Guy Fawkes night as you advise contractors of your plans. Remember, that this is a worrying time for contractors whose livelihoods are potentially about to change. Prevent undue worry by engaging and informing your workforce throughout.
By Christmas and New Year, reflections on "another year over and a new one just begun" should be complemented with reflections on your current contractual arrangements and amending them to fall in line with April's changes.
The first quarter of 2020 should then be a time to prepare to hit the ground running: training your people on any new processes, engaging stakeholders, assessing new job roles and adverts for compliance.
Then, my favourite: by April 2020, you should have a bottle of champagne in the fridge ready to toast all your hard work and your organisation's compliance.
Glancing at these, you may feel your heartbeat start to race and your blood pressure begin to rise. What if you're late? Don't panic! We've been through this with the Public Sector and we are here to help your business, wherever you are in the journey. You Are Not Late.
One of the most common lines we hear from clients is "we are so late" and, looking at the calendar, this may be your reaction too.
In truth, you're not late. You are where you are!
Remember those three words: YOU ARE HERE!
It's the quality of your response to this that will matter in April 2020.
I had this exact "we are late" argument with a HR Director friend who said that having embarked on a compliance mission after the Public Sector changes, his firm was now six months late. Then two months passed, not much progress was made, and he told me they were now eight months late. It took me a further month of telling him "You are here" for him to accept this and take positive action - (thank goodness, otherwise by this point he'd have been nine months late!!!)
The point of this is that you will be late if you are not compliant by IR35 day, until then YOU ARE HERE.
So, accepting that, what's your next step?
Find out more about IR35 and PMaaS
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.
The reasons that project teams ask for help are manyfold, sometimes the project is more complex than the client's in-house capability and experience, at other times a stretched portfolio requires more resources and then at other times a client may have no in-house facility and need end to end Project Management Office services.
Then .... there are the emergency cases.
There have been many surveys and studies on how many projects fail over the years and they have pretty much all been above the 50% mark. Imagine if over half of trains were late, or over half of hospital patients didn't survive operations, or over a season Manchester United lost over half of their games, actually that last one is a bad example right now, but you get my point. Questions would be asked in any other industry facing such failure rates.
We took a look at the reasons behind many of the emergency calls that we had received, and a trend started to emerge, they seemed to fall into two main categories.
Planning and Proactivity. As with most project problems potential solutions are available in the Project Management as a Service market, more on that later but first let's drill down a little deeper.
Let's start with ...
1 - Planning ...
"Proper Preparation Prevents Poor Performance" (and slightly more colourful variations of this) has become a bit of a business cliché over the years.
Despite this, many projects are starting without the necessary level of planning.
Often, projects are started too quickly because of well-intentioned over excitement. Let's face it, when you have pitched an idea that you are passionate about and you get the green light - it is understandable that you want to crack on as a soon as possible. Subsequently, we are seeing projects run aground later because the planning phase was rushed, and not enough consideration was given to risk or any potential issues or concerns, in a recent case, even concerns that were flagged up by a client were overlooked by a project team who rushed at their project like an over-enthusiastic Labrador puppy! In these times of increasing complexity, it is more and more essential that teams put proper care into the planning phase.
Before we lay all the blame at the project team's door, clients can have a hand in disrupting the planning stage too. In a recent case, a client's over-reliance on their project partner caused problems as both service provider and client assumed that each other was asking the right questions to plan for any challenges that might occur.
In another, the client had not initiated an IT Project for a long time and assumed that the project was within the capability of their in-house team, the team was rusty, and the new project was more complex than previous ones. They soon reached out for help but not until after the project had started - proper planning would have flagged these potential concerns ahead of them becoming a real-time problem.
Then, there is the "figure it out later" brigade.
As a fervent planner, I always used to have a reluctant admiration for project managers and teams who seemed able to fly 'by the seat of their pants' through a project. As Projects have become more complex and increasingly business case linked though, these types of PMs are enjoying fewer successes. To leverage the maximum benefit from a project you really have to have deliverables and milestones clear in your mind before you start. The days of knowing what the end result will look like and then filling in the middle as you go along are confined to history. Ironically, even former 'seat of pants' project managers are finding that by having crystal clear objectives, properly allocated resources, realistic timelines and projects that are planned in manageable, properly delegated chunks of work, they have more freedom to improvise responses, rather than less.
2 - Proactivity
Far too many projects are failing because the teams leading them are reactive rather than proactive. This follows on nicely from the part about flying by the 'seat of your pants' because the other discipline that these project types need to learn is the art of defining risks before a project starts. I read somewhere that this is the cause of about a third of project fails, certainly anecdotally when we are asked to rescue a project, it is often the undefined risks that have broadsided teams.
Contingency planning is key to the success of a project and the more experience you have, the more you start to see patterns emerge in the things that can hamper even a well-planned IT project.
A friend told me about how she and her team were working on a project that had hit challenges because the regulatory landscape for their industry changed and the project, as scheduled for delivery, would no longer be compliant. I think that she was expecting sympathy, and as a friend, I gave her some, but as a fellow project professional, I wondered how long the regulatory changes had taken to pass through parliament and whether she could have realistically anticipated them. Indeed, the white paper on the subject predated the planning stage for the project so there really wasn't any excuse.
As, a kid I remember seeing a darts player, John Lowe, interviewed after a match he'd won. Before he threw the winning dart his two previous arrows had hit the wire and bounced onto the floor drawing gasps from the crowd. His opponent also had a potential three dart finish, had he been allowed to step up, so the pressure was on. That third dart had to count! Lowe calmly threw the dart, it hit the target and he won the match. Afterwards, the interviewer asked how he had maintained his composure with the previous two attempts rebounding onto the floor and Lowe said, "I never look at the dart on the ground." I've never forgotten that - he had a proactive plan. A dart hitting the wire and landing on the stage is paradoxically both unlikely and likely in equal measure but so are many of the things that can derail an IT Project. It’s your preparedness to respond that can make all the difference.
The point is, anticipating problems and knowing how you will respond is a great skill, a skill that you get better at the more experience you have, and which gets easier the more thorough your planning stage is. That's where the third P of the pack comes in - PMaaS. The Project Management as a Service market has resources from single talent to end to end Project Management Office to help fill planning or proactivity gaps or whatever capability issue you encounter. The more flexible PMaaS partners allow you to dial up and dial down the resource you hire in sync with your needs at any given time.
Project failure rates are still worryingly high but with a universe of PMaaS resources available and proper planning and a more proactive outlook, the industry has a real opportunity to put things right - it is within our power. I just wish we could do something about Manchester United!
However, five years back a project team using Waterfall on a project that was more suited to Agile might have got away with it. I mean, perhaps they wouldn't have leveraged all the potential, they may, for example, have been slower coming to market than they would have with Agile but broadly speaking they could deliver a successful project.
Now, as projects become increasingly complex and more closely aligned to business goals, choosing the right methodology REALLY makes all the difference.
The choice of project management approach (how a project is planned, executed and delivered into service) can have a huge strategic impact. Choosing the wrong project management methodology is often mentioned as one of the main reasons why a project has failed. In these cases, teams will usually have opted for one single methodology and stick with it as an end to end solution. Actually, a hybrid combination of elements from a multiple of methodologies might have worked better. Project management methodologies are often selected at a broader organisational level with little thought given to the specifics of an individual project – that has to change.
Successful teams are finding that it's not just that one methodology won't suit all projects in their portfolio, it's moreover the case that one approach is not best fit for all the individual elements of a single project.
A recent report from PMI points to growth in the volume of IT Projects being delivered using hybrid methodologies where you take parts from different methodologies, elements that have a proven track record of securing successful delivery and combine them to create a more efficient delivery system. This backs up what we are seeing and the rise of hybrid methodologies in IT Project Management is very exciting because the potential for innovation grows exponentially!
This growth in adoption has resulted in a growing demand for Project Managers with the ability to apply a varied approach but they cannot always be found by looking in the usual places. Many businesses are looking to a trusted Project Management as a Service partner to provide a more diverse outlook. The PMaaS market, by its nature, has an abundance of talent and solutions ready hit the ground running.
The problem is that often methodologies become hard-wired into the way a project team or individual works or the methodology becomes such a comfort zone that teams are reluctant to try new approaches. I once had to referee a heated debate between two project managers who were coming at the selection of methodology from very entrenched positions. It was like they were discussing their religion or their allegiance to football teams rather than how to get the best out of an IT Project.
A Project Manager I know called Kev compares this entrenched position to his leisure activity to illustrate the limitations. Kev is a triathlete and he says that sticking blindly to a methodology is like identifying that the way to win one part of a race is the key to winning them all. "The bike for example, would help you speed past the other athletes in the running bit, but then you'd enter the lake and sink like a stone."
He's got a point.
There's a reason why you pack trainers for the running part, a wetsuit for the swimming bit and Sudocrem for the cycling! They work best for those individual disciplines but as total solutions for the end to end race they'd be, at best, less effective or, at worst, useless.
If this sounds familiar, from an IT Project Management perspective, using PMaaS resources can certainly help.
I saw a client apply this thinking to an IT Project recently, using PMaaS talent and a hybrid of (mainly) Waterfall and agile. They used waterfall to map the project's path, starting with establishing the project's requirements and specification and through the development, testing, and delivery stages. For all of this Waterfall was king but then they distilled the project down to its constituent component parts and found that for these Agile was more effective. Agile was deployed to develop, refine and then release each individual component and, because IT Projects are like Russian dolls, most components had a layer of components within. Agile was effectively used to deliver these too.
The use of Agile clearly accelerated delivery of the component parts and played a huge part in improved quality standards too. Each component part of the project was 'chunked' into tasks, given a timescale and Agile was used to complete and then release each component, in most cases to be used as the foundation for the next phase of component tasks.
Waterfall was used to knit them all together, manage dependencies, co-ordinate 'high level' tasks and deliver the overall project. Using a hybrid of methods, the client delivered a higher quality project to market and much faster than anticipated.
Even better, during the course of the project there was disruption in the market from a competitor and, thanks to their use of Agile, the team was able to potently react and respond.
My colleagues and I have written many times over the years about the need for more joined up application of project methodologies and I am thrilled that use of 'hybrid' approaches is on the rise.
Letting go of tried and tested methodologies and mixing things up is a big step away from the comfort zone for many but the results are so worth it.
All that pitching, planning and preparation has led to this point! You are ready and raring to go and as you line up the road ahead, your attention will have turned to how you document and communicate within your project. At this point, you are probably thinking about initiating a RAID log. You can knock one up in Excel, one of the most effective tools you can easily create for your project ... until now ...
RAID logs are pretty cool!! RAID is mentioned in all project methodologies, I can't think of a Project Manager who doesn't use one.
However, I also can't think of a PM who doesn't also use other documents alongside it. Simplicity is one of the advantages of the RAID log but it is also one of its drawbacks. Risk, Actions, Issues and Dependencies are neatly covered by the RAID log, on one single document but often project teams find that they need other documents that review and record change, decisions, lessons learnt etc.
Your problems can really start when something happens in your project that doesn't fit into one of these tabs - what then? This is where PMs either turn to a separate document or, worse still, try to keep all this information in their head. The trouble is that with everything going on across your portfolio there's likely to be a lot going through that head of yours and, being human, PM's forget! Truth is, what's not recorded well cannot be monitored, reviewed and acted upon.
Even when things are well recorded on separate documents, maintenance of these many documents can be confusing for clients and stakeholders and it is often in this confusion that mistakes can occur that leak value.
So often, a RAID log doesn't always give a full and accurate picture of the status of the IT Project.
Many Project Leaders and CIOs said that they needed something more RADICAL.
Appropriately, together with my colleagues at Stoneseed (the IT Project Management, Technical and Service Delivery specialists), we streamlined the management of project related documentation into one RADICAL log.
Let's break it down;
Stoneseed's RADICAL log covers;
R - Risks
A - Actions
D - Dependencies
I - Issues
C - Changes
A - Assumptions/Decisions
L - Lesson Learnt
The advantages are many, but chiefly;
1 - Having one document works better for the client ...
... and it works better for you. Rather than updating various documents, the RADICAL log gives you real-time transparency. To have all project related info in the same place, a holistic overview provides you with the opportunity for a regular look at everything! It is a living and breathing single document rather than a hunt for information through loads of documents
2 - Using one document means that events are MORE likely to actually get recorded
On this, a Project Manager friend compares RAID logs to when you put the bins out. He says. "We have different bins for recycling paper, card, plastic, glass, garden waste, etc. The other night I had some rubbish that I couldn't fit into one of these categories! I agonised for a few minutes and then reluctantly threw it into the general bin. In many projects, this has been what has happened to, for example, a valuable lesson that has been learnt. Where do you document that? It's not a risk or an action, neither is it a dependency nor an issue and yet paradoxically, a lesson learnt could be all of these! So, traditionally, lessons have ended up in the RAID log equivalent of our green bin and have been missed by other project team members."
3 - You declutter each category
I was asked to help a project team with a floundering project last year. The first thing we did was look through the recorded documentation for clues - from project charter to the delivery into service plan, everything seemed meticulously prepared. Then, we looked at the RAID log and oh my days!! Each category was pages and pages long giving a very unclear instant picture of the health of the project.
At RAID review meetings the team ran through the whole document starting with the risk section which, from memory, was about seven pages. Now, many of the entries were not really risks - more assumptions or concerns that fell into a bit of a RAID grey area. However, because of the RAID methodology, there was nowhere else for the team to register these "grey area concerns" so they had been lumped into 'risks'. The result was that when the team met on a weekly basis, they only had time to chat through a couple of pages of the whole RAID log (all risk - i.e., stuff that might never happen) and there was insufficient time for proper consideration of actions, issues and dependencies - the real day to day life of the project.
Of course, better prioritisation would have helped. Even using a RAID log there were things this team could have done better. Low-risk projects require that the team spend less time discussing risks versus, for instance, issues, there was a failure in the implementation of this teams RAID log. That said, filtering log entries further using the RADICAL approach means that only bona fide risks make it onto that part of the spreadsheet because there is place elsewhere for grey area concerns.
4 – RADICAL improves response quality
The items in each of category of a RAID log necessitate different follow-up methods. The difference between an "issue" and a "risk", for example. The former is a cast iron problem - it's something that needs action, perhaps changes and there will be lessons that can and should be digested. A risk, conversely, is a potential problem, effectively a problem that hasn't happened yet - it still needs attention, solutions that may never be used must be brainstormed but in many cases, action is not required. On a standard RAID log the results of these brainstorms can get lost at this point - where do you log decisions for future reference if the risk becomes a reality? The RADICAL log provides a natural place to register these decisions.
5 – RADICAL makes you think about the project as a whole.
The RAID log is a brilliant tool and it really focusses your mind on the things that you have entered into those four categories. This can be a problem too. If you were told to notice how many vans, buses, cars and lorries you saw on your commute into work, every time you saw a vehicle from this category your subconscious mind would notice. You may arrive at work having not noticed all the motorbikes, milk floats and tractors you passed.
Much of your project brilliance comes from when your primary attention is focussed elsewhere, that is to say, that your eureka moments tend to come from your subconscious mind as opposed to when you go looking for them. When you limit your main project log to the four categories of a RAID log (and jot down other project events in separate documents) you train that part of your brain to limit awareness and thinking to Risk, Actions, Issues and Dependencies.
Using a RADICAL log extends your project awareness and encompasses a more holistic set of performance criteria.
Having one document, that is living and breathing, means you are always working on it and are, therefore, always aware of what is going on - everywhere!!
In conclusion, it is appropriate that this new approach is called "RADICAL" - project teams using it for the first time say this is exactly how the results feel. It's exciting! To return to my opening sentence, where I invited you to imagine the implementation phase of an IT Project, exciting is exactly how it should feel. Right?
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!