Straight Talk On Project Management - Volume III

Colette explained that she didn't have any money, swimming costumes are not really designed for
purses and again explained about her intention to join the gym if the pool were fit for her needs and
again said that it had been previously agreed.
The manager insisted that Colette would have to pay, but said that they could refund the £10 from
Colette's first monthly subscription if she joined.

With reserve not normally associated with Colette, she declined the offer, got dressed and went
back to work.

Now, the cost of an annual gym membership would have been £480, Colette also has a massage
each month - so that's another £420 a year. Add to that the occasional nail and waxing sessions and
in the space of ten minutes that manager has probably talked herself out about £1500 of business a
year - because Colette won't be going back!

Plus, Colette is the "Culture Champion" at her firm and had previously asked at the spa about
corporate membership deals. She was in the process of compiling a list of interested colleagues. If
only half of them had signed up, the gym/pool/salon would have made tens of thousands of pounds.
All gone now, for the sake of ten pounds.

There are, as I say, plenty of lessons from this story for those of us in Project Management, not least
that you should never wander into reception dressed just in just a swimming costume! Here are just
four more!!

1 - Always Think Bigger Picture
The manager of the spa did what a project manager on a large IT Project did recently. By over
focussing on compliance and process for a relatively small part of the project, it's easy to take your
eye off the long-term plan and potential benefits.
The IT PM ended up delaying several other dependent units of work and ultimately, the project as a
whole delivered late because he was over cautious. If he'd used his gut instinct (which was that a
software integration had gone well) they could have moved on and delivered the subsequent work,
while still carrying out full tests to confirm his instinct. Instead, he followed process and carried out
all testing before signing this particular module off so that the project could proceed. Sometimes,
experienced Project Leaders have to trust their instinct (developed over years of experience) … and
sometimes spa managers need to see how waiving a £10 fee could result in tens of thousands of
pounds worth of business.

2 - Stick To What's Been Agreed Unless It's Gonna Totally Scupper Your Project And Empower Staff
To Make Basic Calls!
I love it when a team is functioning so well that the project leader can delegate the small stuff. The
trouble comes when the project leader then destroys that culture by interfering where it is not
needed. As part of a project to improve customer experience last year, a team had to install 15 iPads
into a retail shop floor environment. The iPads had been unboxed and the firm's app installed, the
staff had been trained on how the get the best out of it. The plan was that when a customer asked
for something not in stock, it could easily be ordered in store and delivered to their home the next
day.

Two days before the project was to go live it was discovered that, when the rubbish from the
accompanying refit was cleared away, 15 iPad boxes complete with 15 iPad chargers had gone off to
landfill too. A quick-thinking team member ran to the Apple store (in the same shopping centre) and

bought replacements using her own debit card. Instead of heaping praise upon her and thanking her
for saving the day, the project leader was not happy!! There was no requisition note, no order
number, the purchasing team had not been consulted, this wasn't in the budget ... he reeled off a
volley of moans and told her to take the chargers back - this really demotivated the team. It also
made the project leader look a bit daft when, because the preferred supplier couldn't fulfil the order
in time, the purchasing manager said, "Just run round to the Apple Store and buy some. You can
claim it back on expenses."
In the same way that there was no need for the spa manager to interfere with the two lengths swim
Colette had agreed, there is often no need for project leaders to sweat the small stuff - unless, as I
say, it's going to scupper the project!
3 - How A Good Experience Can Turn Sour

Colette's massage was all about relieving stress. It worked. What followed totally erased this though!

In IT Projects it can be very easy to deliver lots of good experiences but have them erased with a bad
one. Imagine an IT Project team that accommodates scope creep requests but then delivers the
project late or over budget. This actually happens more than you think! The accommodation of lots
of little extras feels great for the client, stakeholders and the project team at the time but it is funny
how, when faced with a bigger bill or a delayed "go live" day, the joy those extras delivered is soon
forgotten.

4 - Not Being Clear About Deliverables, Not Realistically Managing Expectations - Isn't That (Sort
Of) Lying?
In my early days, I remember an IT Project Manager at an IT services provider whose motto was "The
answer is ALWAYS yes". He would agree to all manner of requests from clients (via the sales team)
and worry about it delivering it later. It was all about getting the business! Often, it worked out, but
sometimes it didn't and the account manager would have to go back to the client and explain on
behalf of the firm why a project would be late or how much more it was going to cost. One day, an
exasperated customer asked, "Why does your company always lie?".
Reputationally, failure to deliver doesn't reflect on the sales team or the IT project manager and
their team, it reflects on the view that customers have of the business. Your business.

Back the spa, Colette was told that the receptionist, who was new, was to blame. The manager could
not apologise enough. It was the receptionist's lack of training, her inexperience … Colette didn't
have a problem with the girl, she had a problem with the spa business, in not being honest and
realistically managing expectations, "it" had lied.
The upshot of all of this is that Colette has joined another fitness centre!

And the fitness centre does massages too, so the spa back at the hotel can kiss that business
goodbye as well.
I do have some sympathy with the spa manager - she probably has her targets and pressures and
perhaps thought Colette was trying to blag a free swim! Sometimes we, in IT Project Management,
can get lost in our day to day stress and not always make the best judgements. Fortunately, YOU can
always call on a Project Management partner who can make the whole thing as a relaxing as, well, as
relaxing as having a nice massage (and we won't chase you down the stairs in your swimming
costume afterwards!).

Conflict - your greatest IT project opportunity?




It's great when an IT Project progresses from
implementation to delivery without a hitch, an event
free ride from start to finish with no bumps in the road.
Or is it?

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.

Straight Talk On Project Management



Chapter Three – Developing the PM team



WISE WORDS


"Unity is strength... when there is teamwork and collaboration, wonderful things can be
achieved." ~ Mattie Stepanek

"Talent wins games, but teamwork and intelligence wins championships." ~ Michael
Jordan

"It must be considered that there is nothing more difficult to carry out nor more doubtful
of success nor more dangerous to handle than to initiate a new order of things." ~
Machiavelli

"Goals are dreams with deadlines." ~ Diana Scharf

"I feel that the most important requirement in success is learning to overcome failure. You
must learn to tolerate it, but never accept it." ~ Reggie Jackson

Eliminating the IT Project Unpredictable – It’s More Judgement Than Luck




"Well that's a bit random!" said a Project Manager I was
sat with recently as his project threw up one of those
curved balls that only seem to happen at 4.59pm on a
Friday, just as you're about to clock off for the
weekend.

The project had cutting edge visibility so the "random"
occurrence in question could be acted upon quite
quickly and corrective action was taken before anyone
even really knew there was a problem. It meant a later
night that Friday though!

The Project Manager sighed, "Oh well, the
unpredictable stuff is what makes an IT Project
interesting, right?"

I admire that philosophical viewpoint, but personally, I like starting my weekends on time. I
wondered ... is anything really random and unpredictable in IT Projects? Could this have been
avoided?

Randomness and IT Projects seem, unlikely bedfellows, I mean, a computer's output is dependent
upon input - that's what GIGO (garbage in, garbage out) was all about! So it is with IT Projects. Do we
just need to get better at identifying when garbage has gone it?

Tech journalist, Bill Thompson told Radio 4's The Curious Cases of Rutherford & Fry, "Computers
don't do random ... they are a designed to be predictable and the best we can achieve within a
computer is what we call pseudo-randomness where you have a complicated seed number that is
supposed to be unpredictable and then an algorithm which takes that seed number and generates
from it numbers which are supposed to be random. The problem is if you repeat the seed and repeat
the algorithm you'll get the same pattern of numbers out." You could illustrate this for your self - if
you opened an online random number generator, and analysed results, over time you'd start to see
a pattern emerge.
So, how can you spot patterns that emerge within your IT Project? How can you start to predict IT
Project Management 'random' outcomes - before they cause problems?
To find the answer, forget the online random number generator - let's go analogue!

Roll with me on this (pun intended).

Do you have access to Monopoly or Yahtzee?! Grab the dice, pick a number between one and six
and roll them - repeat, repeat, repeat. How many times did you predict the right number? What this
demonstrates is the apparent randomness of dice rolling. Dice are, after all, meant to introduce the
element of random chance to whichever game you are playing. Who hasn't been six Monopoly
spaces away from jail, rolled a double three and exclaimed, "What are the chances?!"

What if I told you that even dice rolling was not as unpredictable or random as it seems? The throw
of a die is, after all, governed by Newtonian physics so if you could have access to data like the speed
of the throw, the starting position of the die and the thrower's hand, the weight of the die, the air
pressure in the room, you could, in theory, predict what number would result from your roll.
Actually, researchers at the Universities of Aberdeen in Scotland and Lodz in Poland created a
sophisticated theoretical model of a die throw (in their study The Three-dimensional dynamics of the
die throw). They filmed the die with a high-speed camera and considered influences of gravity, air
resistance, the friction of the table, and other factors and assessed which of these could most affect
the outcome.

What did they find was the most important factor?
"The initial position of the die," Tomasz Kapitaniak, from the University of Lodz told Inside Science's
Ben Stein.

There's the lesson for IT Project Management ... the secret of predicting 'random' outcomes lies in
knowing the initial, starting position.

So, back to that IT Project that delayed the start of a weekend.

The Monday after the Friday before, the Project Manager and I had tracked back looking for a trail.
We were searching for a missed red flag that might have allowed earlier identification of this
"random event" in the future. It didn't take long for us to find the exact moment where the problem
started - the initial position. We traced that Friday afternoon bug back to an inadequately tested
software component developed weeks before. It had been tested back then, warning signs had been
missed and as the software development life cycle continued this one component had become
increasingly unstable until, eventually, it fell over.
Finding the "initial position" of a problem allows you to correct it and also adjust your processes for
the future. In this project, continuous testing of smaller component parts as they are being
developed will ensure that this doesn't happen again. The cost of fixing issues in later stages of an IT
project is usually much greater than the cost of fixing sooner, as you go along, so it makes business
sense to work this way and keep project costs in control. This team had just got busy and missed
what their testing had been subtly trying to tell them. They won't do that again!

As IT Projects become increasingly complex and crucial to your organisation's strategic business
goals, it's important that we all get better at predicting the unpredictable. It can help to have a
trusted IT partner run an independent pair of eyes over your IT Project issues and you can buy in end
to end Project Management as a Service (PMaaS) solutions that bolster governance and
transparency. This will make "random" problems less likely or, at least, easier to track back to.
Ultimately though, IT Project teams must accept responsibility for the "unpredictable" because,
frankly, nothing is really unpredictable, just unpredicted.

How planning, proactivity and PMaaS prevent poor performance projects





Over the course of this year, I have been asked to
consult on many IT Projects. As always, I consider this a
huge privilege, and nothing gives me greater pleasure
than helping an organisation achieve successful project
outcomes.
The reasons that project teams ask for help are
manifold, 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, but you get my point. Questions would be asked
in any other industry facing such failure rates.
We had 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.
Why?

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!

Is IT Project Management doing enough to make Tim Berners-Lee proud?





I started to write this on the day that the world's media
declared that the "internet turned 30".
OK, without getting nerdy, although the terms are often
used interchangeably, March 12, was actually the 30th
anniversary of the World Wide Web. But hey, semantics
– right?! Whatever you want to call it, it has been
transformational.

I was listening to the radio and the presenter and callers
were having fun remembering how things used to
before the web (if you wanted a blouse - you had to
visit a High Street store said one - oh the humanity!!!)
and they were listing things for which they are grateful.

As the programme went on, it started to dawn on me that the majority of callers were only using the
internet for a fraction of its potential. One woman actually said her ABSOLUTE favourite thing about
the web was the funny animal videos!!! Also, many were still using the internet the same way they
had when they first encountered it, typing Google searches rather than calling for Alexa, for
example.

This got me thinking.
Ask anyone who was working in IT in the days before the web, what it was like. They’ll tell you how
the internet has been even more transformational for us, but, just like these radio callers, are WE
getting maximum gains from it and the IT advancements it has brought?
Sometimes we can forget how much the internet has changed things and how quickly that change
has happened. As businesses and organisations, we can be guilty of not updating our perceptions of
what's possible, or how we use it, and so get left behind. The available technology and solutions
have outpaced a lot of organisations’ ability to keep up.

I asked IT Project friends why they'd like to buy Tim Berners-Lee a drink ..

And this is what they said ...
1 - Knowledge is power

This came up in the radio phone in! The history books are full of how, throughout time, knowledge
was restricted to the elite. Not anymore! YouTube has thousands and thousands of hours of
educational videos (and plenty that are not quite so educational too) and Wikipedia is a reference
library of millions of entries on everything from particle physics to over 5,000 words on the
orientation of toilet paper (over or under?) and, closer to home, CIO.com and pmi.org are fabulous
resources for IT Project Management. Thanks to Tim Berners-Lee's invention anyone with an

internet connection can access the sum total of human knowledge - from a device that they keep in
their pocket.

Some of the Project Management forums are a great source of inspiration and information and often
it is a great comfort to find someone, maybe on the other side of the planet who has struggled with
the exact issue that is keeping you awake at night. There is a whole section coming up on Project
Management as a Service but thanks to internet connectivity there is a limitless resource for project
management solutions. Which brings us on to ...
2 - Communication!

Do you remember the days when you would coordinate (even) an IT project in your conference
room? With the advent of cloud computing, with mobile applications and constantly evolving project
management software, you now have a global conference room. IT Project teams can discuss
projects around the country and even across the world. Anecdotally, I reckon that four in ten project
team members now work remotely, which allows companies to access talent and resources from all
over the world through Project Management as a Service (PMaaS).

It means that developers and those tasked with transition into service can communicate effectively
at times that historically would often leak value. Clients and stakeholders can have access to better
progress updates, fuelling greater transparency and governance.
3 - Access projects anywhere, anytime

And it's not all talk. As well as improved communications teams are now working in real-time on
their projects even when team members are spread across multiple offices.

Your project is always live, always to hand and, as updates sync automatically, always the most up-
to-date version. This has been a game changer in eliminating time waste and driving greater return
on investment (ROI).

Not too far back in the day, cloud-based project management software was prohibitively expensive,
many small to medium-sized businesses were priced out of this market. Now, solutions are more
affordable allowing companies with any budget, to do more and leverage greater returns.

4 - Easier and better compatibility

Compatibility has always been a headache for IT Project Management teams. Many still struggle
with the transferring of data between different software solutions, even with the advent of cloud
computing!

It is an improving situation though and software developers are actively now seeking ways to make
cloud-based project management software compatible with the likes of Microsoft Office and
Outlook, for instance.

5 - The PMaaS (Project Management as a Service) universe has exploded
Project Management as a Service (PMaaS) provides access to project professionals, resources and
tools at a flexible and predictable cost. Whether it is a true end to end service, IT Advisory,
Programme & Project Delivery or Service Delivery, access to Flexible Resources on demand, as a
Service is booming. Thanks to straightforward cost models, businesses have an ever-increasing
project management toolset to call upon.

Project, cloud transition and migration planning; vendor and system selection and evaluation;
governance; delivery and post-delivery transition into service and stabilisation; cost management
are just a few of the reasons that I would like to buy Tim Berners-Lee a pint!!!
So, there you go. Just five ways that the invention of the world wide web has allowed IT Project
Management to develop and strive; to deliver greater returns on investment; and to move from a
back-office function into a strategic business partner. It’s hard to fully grasp the impact of the Web
on IT Project Management, largely because without it, none of us would actually be doing exactly
what we do now.

It has been an utterly transformational technology that has reshaped every aspect of modern life but
especially ours!
The problem is, that just like the woman whose favourite thing online was those funny animal
videos, many businesses are not maximising the potential of these constant advances.

It is our responsibility, as IT Project leaders, to ensure that they do.

Reframing dysfunctional beliefs could save your IT Project



Working with IT project teams for many years now, I've
noticed an easily fixed issue that crops up in struggling
projects year after year. I'm sure that I've written about it
before, probably more than once and as it just happened
again, I thought it worth a fresh reminder.
IT Projects are being choked and sometimes even killed by
dysfunctional beliefs.

Simple as that.
Dysfunctional beliefs are neatly defined by the authors of
"Dysfunctional Beliefs Affecting Stress" as having "to do
with the actual content of thinking itself." Thoughts are
powerful and over time become habits, in too many cases how teams think about the challenges
they face is the greatest problem. My designer friends talk about reframing problems so that they
are answering the right question and that's the challenge that we often face with our thinking.
My designer buddy Sam uses this example to demonstrate reframing.

Imagine you're at work on a cold, dark, wet November morning. It's raining so hard you can hear
each raindrop smash against the corrugated iron roof of the office unit you are in. The wind is
howling. You need milk from the local shop for your morning cup of tea. You're gasping for a brew
but having tea without milk doesn't bear thinking about, I mean yuck!!! BUT You don't want to get
your work clothes wet; who wants to sit in a soggy suit for the whole rest of the day?
What do you do? Most people start to think 'how can I get to the shop for milk without getting
wet?'.

Take an umbrella? What about that wind?

Wear a raincoat? What about your legs? Soggy skirts and trousers are no fun!
You could run? Or drive? It's raining so hard that you'd literally only need to step one foot out of the
door to be soaked.
The designer is minded to reframe the question so that it fits the actual problem. The problem isn't
anything to do with the weather, or the shop, or even the milk. You're gasping for your morning
cuppa remember - the outcome you want is to be drinking tea. The reframed question then is 'how
do I get a cup of tea' - well it turns out that the local café delivers hot beverages and also has a really
nice selection of cakes; perfect for a lousy morning!

Maybe some examples from the IT Project Management world will clarify this. Here are five that I've
encountered recently.
1 - "Hiring in Project Management as a Service resources is costly"

A CIO whose project was about to sink said this to me, having reached out for help.

Two things here, first, the cost of not saving this project far outweighed any potential cost impact of
taking action; the project was a key strategic business IT initiative and it was too important to fail.
Secondly, often Project Management services can be accessed without net increases to your overall
project portfolio budgets. It's worth asking the question at least. Your Project Management as a
Service partner can help.

2 - "The buck stops with me, as a leader I have to cope with everything"
This is a bit of a throwback.

I think most of us remember a "my way or the highway" type of project manager, a macho, alpha
male type who was a bit of an ogre. These days project leaders are different, we are mostly great at
delegating and while it is true that, as the person driving the project, you have responsibility for
keeping it heading in the right direction, a project's success should never rest on just one pair of
shoulders. Delegate to your team and dip into the Project Management as a Service universe for
extra resources.
3 - "There's no room to make mistakes"

EEEEK! The best lessons that I've learned in my IT Project Management career have been thanks to a
mistake that I or my team have made. Messing things up should be a basic human right protected by
the United Nations! Post It notes, microwave ovens, Penicillin, inkjet printers, and potato crisps were
all invented "by mistake".

You should build in room for mistakes and make sure that you and your team learn from them.
4 - "The project is late"

Shhhh! Don't ever share this with your stakeholders; they won't appreciate it. The thing is - labelling
your project as "late" is really demotivating. So, it's not late ... it's ... well, it's where it is. Once you
have accepted where you're at you can deal with that!

Dave Evans, from the Product Design Programme at Stanford and author of Designing Your Life puts
it nicely when, in a Stanford e-corner lecture, he asked students if they'd ever felt 'late'. "For what?"
he asked. "There is no such thing, you're just here."
I love football when Manchester United played Bayern Munich in the 1999 Champions League Final
they equalised after the ninety minutes had elapsed. Were they late? When Solskjær scored the
winner three minutes into injury time was he late?
No!! 89 minutes into the game the reds were losing, they weren't late, that was just where they
were and they dealt with it.
If you find that you are 'behind' and you realise it, then you can do something about it. Call your
PMaaS partner and ask for suggestions, make adjustments to your portfolio and re-allocate
resources, get advice from an expert at delivering projects into service.
Even a project delivered "late" is a project delivered. Cut yourself some slack!

5 - "I have to get all of today's tasks done today"

Yeah, in an ideal world, in a perfect workplace - you'd get everything on your stuff to do list done
today. Life and work don’t always run to plan, there are fire drills and "happy birthday to yous" to

sing; there are phone calls and emails with red flags on them; there are power cuts and power
struggles.

I worked with a guy once who used to (jokingly) say, "He who achieves everything today, gets made
redundant tomorrow." It was his way of taking the stress out the fact that tasks were regularly
getting passed forward to the next day.

I think that as long as you have a plan and a schedule for how you'll achieve uncompleted tasks
tomorrow, you can tick them off today's list.

On a serious note, if you are finding that you are carrying many tasks forward every day, this may be
a sign of insufficient resources. Again, having a fresh pair of eyes look over your workload can help
and there are plenty of resourcing solutions in the Project Management as a Service market.
This week try to watch your thoughts and assess them to see if they are serving you well. Make it a
habit to play devil's advocate and challenge yourself and how you're thinking. Ask others for input,
take views from people who are different from you and get an independent, fresh pair of eyes to
take a look at your operation once in a while.

You literally would not entertain dysfunctionality in any other aspect of your project team, why
should your beliefs get an easy ride.




Sources:
https://www.mentalhelp.net/articles/dysfunctional-beliefs-affecting-stress/

https://www.storypick.com/inventions-made-by-mistake/
https://ecorner.stanford.edu/video/designing-the-life-you-really-want-entire-talk/

Successful IT Project Teams watch their language


"What can we do better?"

"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.

Why?
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?


Sources:
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)
apm.org.uk

https://www.apm.org.uk/news/nlp-for-project-managers/

The rising value of the IT Business Analyst



The evolution of the IT Business Analyst role is
increasingly seeing the job description stretch beyond
the "IT" further into the "Business" territory. This means
greater career prospects for analysts but also real
challenges for businesses who do not have a character
like this on their team.
It's an exciting time to be a BA but some businesses are
not benefitting from the expanded potential. Either
their BA hasn't adapted in this direction, or the business
processes are too rigid to allow role evolution, or
perhaps (as is often still the case) they haven't got an IT
Business Analyst at all. The IT Project Management
services sector is geared up and ready to help with all
these scenarios and more.

Here Are Five Examples Of The Rising Value of The IT Business Analyst (or things that could be added
to the job spec!)
1 - Defender of business case alignment

Often client/stakeholder requirements are prioritised as hot or lukewarm, but these priorities can be
based on perception and personal agenda, rather than real business impact. The real danger here is
that unchallenged, this can cause an IT Project to veer off course and not deliver intended business
benefits. A good BA realises when this happens and therefore keeps the project focused on business
case, filtering the requirements against strategic objectives and driving results that benefit the
business as a whole.

A CIO colleague puts it, "A good BA is plugged into the whole matrix! They understand the project's
relevance in relation to business objectives and display a passion and tenacity for keeping them
aligned. Great BAs actually save organisations time, money and wasted resources"
2 - Improver of business process

BAs are stepping beyond their traditional role of simply evaluating the value of IT to the business.
More and more, BAs are evaluating the actual business process at their organisation, that is they are
assessing the very thing that drives the need for the IT Project in the first place. As their
understanding grows, they are better placed to not only help manage change after delivery into
service but actually help shape business process against best practice, cutting edge IT. A real
WIN/WIN for the organisation.

3 - Strategic thought leaders
BAs are also getting involved earlier at the stage when thoughts about IT investment are being
formed and decisions are being taken. This makes sense, BAs have shown their value in tactical
operational areas and these skills are instantly transferable to the more strategic design stage of IT
Project Portfolios.

BAs I know who operate in this way grow their influence within the organisation and many have
become a conduit through which most business functions flow.

4 - Multi-project specialists

I think that it fair to say that many Business Analysts still work on one project or one system at a
time and while this may be down to scope and scale or less confidence in the robustness of systems,
it could also just be down to a failure to evolve.

Increased use of agile processes, fewer larger scope projects and better breaking down into 'chunks',
more robust "off the shelf" solutions are all giving Business Analysts space and freedom to handle
more projects at a time. BAs working this way are delivering savings not just in how IT Projects
function but also how they themselves operate.
5 - Multi-system competencies

Traditional IT systems were built to deliver a single business need. So businesses would end up with
several siloed IT systems all delivering different requirements. Many did not talk to each other and
as they were often bespoke and expensive - businesses were loathed to replace them.

The growth in commercial off-the-shelf (COTS) software packages changed this. Solutions which are
bought off the shelf and then adapted to satisfy the needs of the purchasing organisation are
cheaper than commissioning traditional custom-made, or bespoke, solutions - so businesses are
filling their shopping baskets! The real skill here is making them work together and this is an area
where BAs are really delivering value.
A good example recently was a business that introduced a new IT system for generating delivery
notes. The Transport Director wanted a new automated system to improve on the existing (and
rather quaint) heritage software package that still even required the end user to generate delivery
note numbers "by hand" and write them in a lined A4 book!

Traditional BAs would have worked on this system and this business need would have been
delivered but the hero BA at this organisation saw the potential in linking the new delivery notes
software with other departments. Sales administrators now get a real-time delivery eta to pass to
customers; the delivery note system automatically adjusts stock levels for the store controller to
keep on top of inventory and alerts purchasing when levels are low; and it automatically advises the
accounts department the moment a delivery is made so that an invoice can be raised and emailed
reducing time from delivery to account settlement.

6 - Cross department competencies

A natural step on from all of the above is the expansion of departmental stakeholder groups who
increasingly rely upon support from IT Business Analysts. The best BAs are driving this by using their
knowledge of business processes and weighing up the cross-departmental impact of every IT Project.

These BAs are becoming adept at understanding and prioritising the competing needs of various
departments, they are improving their communication skills and again their circle of influence within
their business structure is growing.

For years, I've said that rather than just supporting the business, in most firms IT now IS the business
- so who better to have at the heart of this than an IT Business Analyst.

In conclusion, although the job title remains unchanged, the role of the Business Analyst is evolving
all the time. Business Analysts that have adapted in this direction are delivering greater results and a
competitive edge to their organisations.
Businesses that do not have such a character on their payroll may be missing out but can access
talent like this from a trusted external resource provider. As IT becomes increasingly driven by return
on investment, to not do so could be handing your competition a commercial advantage that may
come back to bite you hard.

Time for greater emphasis on IT Project WOMANagement?



Guest blog by Nicol Cutts – Stoneseed Head of Projects


May 2019 sees the fifth, annual 'Women in Tech
Festival' in Silicon Valley. Aptly, my invitation to attend
dropped into my inbox at the same time as a reply to a
question that I'd asked a CIO friend whose organisation
has consistently high IT project delivery success rates.

I had asked this CIO for the secret to their success.


"The women on our team," was the reply.


To be honest, at first, I thought that this was a glib remark about 'ability to multi-task' or a cliched
observation about 'bossiness, pushing tasks through'. In fact, it was a genuine, firmly held belief that
the team's output had improved as the gender mix had evened out. More than a belief actually, the
results clearly prove it: success rates improved as more women joined the team.

Coincidence? Is there any evidence that women make better project managers? Sort of! Back in
2007, a survey of U.S. project managers revealed that female PMs outperformed male PMs in key
areas and that women PMs abandoned fewer projects than their male counterparts.

But do women really make better project managers or does a more diverse mix just make for a
better team? And what do you do if there are gaps of any kind within your team?
The tech gender split hasn't always been like this. Women once made up 80% of the computer
industry. These days less than 20% are women and my own experience tells me that, in IT Project
Management, the male/female split is around this mark too. Indeed, in 2015, it was estimated that
somewhere between just 17 and 30% per cent of project managers were women.

A brief history of women in Tech and the greatest IT Project EVER.

I suppose it started with Bletchley Park which I once heard a radio announcer call "the greatest IT
Project ever". The work done there shortened the second world war by months and saved between
14 and 21 million lives, so when I compare these deliverables to some of the ones I stress over these
days, I think "the greatest IT Project ever" is about right!! Although it is the men, like Alan Turing,
who often are remembered, around 8,000 women were employed there during World War II and,
rightly, in recent years, it is the women of Bletchley Park have had their work recognised. Various
books, TV documentaries and the ITV drama 'The Bletchley Circle' have celebrated them and David
Kenyon, research historian at Bletchley Park Trust said: “Bletchley Park could not have functioned
without its female employees”.

The computer industry workforce remained largely female dominated for decades, most of the early
coders were women and jobs in the tech industry were seen as clerical functions.

Marie Hicks, a British tech industry historian, talking on BBC radio programme "Jobs For The Boys"
says, "In the early days, it hadn't yet professionalised, there was this idea that it was rote, and
women were paid less, so girl hours were obviously cheaper than man-hours."
However, things started to change as emphasis switched to the potential power of the tech jobs. As
Marie Hicks explains, "You got to lay out the system that was going to be used to help make the
government-run or help make a bank run or help make an insurance company run." Suddenly there
were exciting career paths available and the men started to get interested.
Women increasingly found it harder to be heard higher up in tech circles. Tech entrepreneur Dame
Stephanie Shirley had to adopt her family nickname "Steve" to be taken seriously! Her tech company
would one day employ over 8,000 people, a similar number to those working at Bletchley Park.
Women for decades reported a culture of harassment and techno-chauvinism even within global
tech giants.

And that's how we find ourselves where we are today, as I say, somewhere between 17–30% per
cent of project managers are women.

So, let's let that sink in:

a) women are great at delivering IT Projects;
b) less than 30% (actually probably less than 20%) of project managers are women;

c) IT Project failure rates remain high.

I can't help wondering if, as an industry, we may be missing something here.
I asked for some feedback from clients, colleagues and friends. Women seemed to have greater
strengths in four key areas and this anecdotal evidence can be backed up with various studies.
A) Interpersonal and non-verbal communication – both key skills for project managers. "An
examination of gender differences in managerial communication of project managers" claimed that
women tended to have greater strengths than men in this area. (Snyder D., McLaurin J. R., Little B. &
Taylor R., 1996)
B) Client Relations - "Clients and stakeholders take bad news from me better than my male
colleagues (who have had some right stand up rows)," a female PM messaged me. In fact, Nath’s
(2000) research with project managers showed that that being a woman made it easier to gain
access to clients, women got on better with clients, and clients were more willing to talk to women
than men, and more willing to take bad news from women.

C) Teamwork - A UK study of women project managers concluded that "women have significantly
more of a team management style than do men, characterized by a high regard for people and high
regard for task, they are less traditional and more visionary in their approach to business, and they
may have a more heightened sense of awareness and a greater sense of cultural incongruence and
gender exclusion’.

D) Empathy - Women do seem more sensitive, caring and empathetic to their staff than men. There
is evidence to support too, these women are "more sensitive in caring for staff and showing concern
than males. They are more capable in interpreting problems and bringing order to their area and are
better able to maintain tight control." One message I received read, "When I was on leave following

a bereavement, I got two communications from work. Flowers from a female project manager and a
text asking a project related question from a senior male project leader."

So, do women make better project leaders? I diplomatically answer this by saying that ‘great project
leaders make great project leaders’, I.e., it doesn't matter whether you are a man or a woman if
you've got it - you've got it.

I think it's a balance of different views, experiences and insights that creates great teams, not which
loo you use.

That said, Silicon Valley Forum’s annual Women in Tech Festival celebrates women in IT, STEM, and
business careers who work to inspire, engage, and empower other women and I'm a huge fan. So,
perhaps it's time we gave similar focus to women in our specific part of the tech ecosystem.
The benefits are there for all to see.




Sources:

https://core.ac.uk/download/pdf/10875055.pdftheweek.co.uk
https://www.cio.com/article/2895538/why-women-make-better-project-leaders-than-men.html

https://www.bbc.co.uk/programmes/m0003t9y

You are not an IT Project Manager. You are not a CIO. How you are so much

more!



I was with a Project Manager friend, Steve, for a catch
up this week when an old friend walked into the coffee
house we were in. I introduced the old friend, Liz, to
Steve and invited her to join us.

After a few minutes, Liz asked Steve, "So, what do you
do?"

What would you have said in answer to that?

If like me, your default response is to say, "I'm a
Professional Services Director" (or whatever your job
title happens to be) then Steve's answer may surprise
you. What Steve said was a little unconventional and it
made me think.

So ... Steve didn't say, "I'm an IT Project Manager". Although, he is.

He said, "I'm a Dad of three, I run, cycle and swim and I'm an IT Project Manager."
Liz and Steve then had a conversation about parenthood and how Liz used to swim for the school
and county teams, Steve said he did too. It was like they'd known each other for years! I struggled to
get a word in edgeways!
After Liz had left I talked with Steve about his response and he told me that for years he too had
trotted out that same answer that you and I would have given. It had often led him down something
of a conversational cul-de-sac. If the person he was talking with was interested in IT Project
Management they would have a great chat, but if they weren't, then what followed was rather
awkward.

"And anyway," said Steve, "she asked what I do. I do more than manage IT projects!"
He's right, of course. Yet we all answer this question in this manner. We all define ourselves and
each other by our jobs but we are all so much more. I started to wonder whether Steve might
actually be onto something and if by defining ourselves in this way we limit our capabilities when
doing the job.
Think about this. Is there something that you do in your spare time that could be a great asset to you
and your project management team? Could your hobby be your unique IT Project delivery secret
weapon?
I asked a few project management contacts and it quickly became clear that everyone has
something that they could (and should) be bringing to the party.


Here's my favourite seven!

1. The creatives! Sal is a painter, Alli bakes the most wonderful cakes from scratch and Bex can make
a piano talk! They are all incredibly creative and, let's face it, often as a Project Manager - you need
to be. Creative minds are great at reframing problems and imagining solutions that seem to come
from nowhere! Bex's dedication to her piano playing also shows a keen sense for attention to detail -
I've never heard her play a "bum note".

2. Rich does mountain climbing! Project Management is all about risk, if you take part in a high-risk
hobby like climbing up the face of a cliff then you have extra project management skills in your
locker. You’re not afraid to take risks, or at least you have the ability to weigh up risk when it
matters. If you can do this when your life is on the line then doing it within the context of an IT
Project will be a walk in the park!! You are also great at picking out the best route from a range of
options and available data (ascending a cliff face that might be choosing an adrenaline-inducing
climb over a boring safe path and in IT Project Management it might be outsourcing project delivery
to Project Management as a Service talent rather than sticking with in-house resources).
3 - Michelle does endurance sports which need real perseverance and persistence. Driving yourself
forward when all you want to do is quit is a great character trait that every Project Manager needs
and something that everyone looks for in a leader. Indeed, Michelle did deliver a project last year
against all the odds, while many project managers (I think I count myself here) may have thought of
throwing in the towel, Michelle was convinced that she could achieve a successful outcome.

4 - Emma is a legend at chess! The strategic qualities of a chess player, thinking many moves ahead
to beat your opponent are exactly what you need to win at Project management. Strategic and
logical thinking, reasoning are all great skills. If you use them in your hobby, you need to bring them
with you to work.

5 - Dean, Pete and Malc all play football. Anyone can say that they are a team player or appear to
be one (especially when their monthly wage depends upon it)! These lads live it every Thursday
night and the camaraderie that they bring to their project management operation has seen them
through much diversity over the years. These lads have each other's backs and will go the extra mile
for one another, sometimes that can be the difference between winning and losing, both on a five a
side footie pitch and in an IT Project.

6 - Hayley is a blogger. She actually blogs about parenting but it's not the subject matter that counts
it's the fact that she has such confidence in her writing that she happily publishes it online for all to
see. Clear, concise written communication is key to project management success. A well-written
brief can deliver a template for success and a proposal that clearly sets out business case benefit can
be the difference between a green light or rejection!
7 - Ellie is a prolific reader. She loves novels but always has a motivational or self-help book on the
go too. What does this bring to Project Management? Well, when you find that your in-house
capabilities are struggling to cope with project challenges you're going to want a great researcher to
enter the Project Management as a Service sector and source solutions. Readers are great
researchers!

You see?
You are much more than your job title! By not bringing all of you to work, could you, your project
team and your employer be missing out?

So, let me ask you again - what DO you do??

Straight Talk On Project Management


Chapter Four – Best Practice



WISE WORDS

"It is change, continuing change, inevitable change, that is the dominant factor in society
today. No sensible decision can be made any longer without taking into account not only
the world as it is, but the world as it will be." ~ Isaac Asimov

"Much may be done in those little shreds and patches of time which every day produces,
and which most men throw away." ~ Charles Caleb Colton

“The sweetest pleasure arises from difficulties overcome.” ~ Publilius Syrus

“When it is obvious that the goals cannot be reached, don't adjust the goals, adjust the
action steps.” ~ Confucius

A hybrid approach to IT Project Management methodology - thought leading
the future



I was in a famous cocktail bar on Saturday night having
a pre-dinner drink and was watching the bartenders
making cocktails.
I was intrigued to see that, although they had a menu of
over fifty cocktails, all of the 'mixologists' were able to
make each drink from memory and without measuring
any of the ingredients. The cocktail bar states, "We are
proud to stay true to the principles of professional
bartending and, as such, we free pour all cocktails”.
AND what a result! Efficient delivery of orders and each
made to specification but not through following a step
by step list of instructions rather as a result of the
experience of the bartenders and the fact that they had
produced each drink many, many times before.

Sounds familiar.

This is how I see the use of project methodology. As Project Managers, we too have an impressive
menu to choose from and when you don’t get weighed down by an overly prescriptive way of
delivery, when you give your teams freedom, within a set of boundaries, you too will get a top result
every time!
I have always maintained that if you put a group of competent PM’s in a room and asked them to
deliver something (with no strict direction as to how) they would naturally take elements of all
methodologies AND crucially their choice of what to use and when would be based on experience,
i.e., what has worked before. Methodologies are frameworks and should be viewed as such, they
should not be seen as prescriptive or as a guarantor of success. It is about application and, as I have
often blogged about before, understanding context.
Most organisations I work with have spent a considerable amount of money and time creating
project management models and templates which allow projects that deliver products and services
that satisfy their specified requirements, standards, and objective. Most have management
structures that are en route to or have achieved a more proactive approach that understands and
draws upon the interrelationships of the processes. If you are familiar with CMMI Maturity Levels, I'd
put most organisations between level 2 and 3, theoretically.

I emphasize the word theoretically. Some consider CMMI maturity levels a little too prescriptive,
that they place project management maturity into five boxes that are way too neat to truly describe
the reality. Indeed, last year (2017), Mark Mulally published a survey that claimed that less than 2%
of the organisations he surveyed operated at CMMI Maturity Level 3 or above. Are the other 98%
chaotically stumbling around level 1 or 2? In this case, as projects become exponentially more
complex surely there would be many more failures. Alternatively, maybe they have found a better
way that doesn't quite fit those Carnegie Mellon University boxes.

Perhaps these project management organisations have established a new maturity - a hybrid
approach?

An Australian PM friend often compares project management processes to his beloved surfing. "Four
to six-foot barrelling waves that you can ride forever are a different proposition to waves that close
out, or get too fat," Karl wrote to me once. "Some days the ocean is tame, and waves are smaller
and other days it's ferocious, waves are larger and more scary. If you approached each with the
same methodology you'd nearly drown once a week. The ocean and your IT Projects deserve more
respect."

Writing for PM Times, Robert Wysocki observes, "Assuming we have competent project managers, it
is safe to assume they have found other alternatives than those provided by their organization and
defined in the project management body of knowledge. Those alternatives are probably variations of
what their organization has provided. These alternatives are not published but travel below the
radar."
I love Robert Wysocki's use of words in this quote. "Not published but travel below the radar"
implies an instinctive, experience-based approach to methodology that is music to my ears and
music is a great place to look for further inspiration.

A cocktail bar (spot a lifestyle theme developing?) close to my home used to pitch up a large gazebo
outside once a year and put on a number of jazz artists. It was a perfect way to spend a lazy sunny
Sunday afternoon. My favourite part was when the artists jammed together. There is something very
hypnotic about watching artists play this way, with no sheet music, just an instinctive feel for the
instruments they play.

In fact, I recall one jazz musician telling me that, when jamming, "I don't play the sax, the sax plays
me. I don't choose the notes; the notes choose me."
I love that! Could it be then, that as experience and context driven "Hybrid Project Managers", we
don't choose the methodology, the methodology chooses us?

Each of the disciplines listed above, musicians, surfers and, yes, even Project Management are
mostly instinctive and intuitive. In each case, greatest success comes when you not only anticipate
frequent change, you search it out and embrace it knowing that you have the correct skills in your
locker to leverage the change to your project's benefit.
Of course, a problem arises when you don't have the skills in your locker - when a methodology
chooses you because that's all you know or have experience of.

Approaching a project or task with all your waterfall experience when it is better suited to an agile
management mindset could be like a surfer taking on that huge barrelling wave but like she thinks
it's going to close out. The surfer can learn from experience for the future and so too can the PM but
here the latter has a distinct advantage in that you can call in talent and resources from the Project
Management as a Service market for the project right now. If you need scrum and all you've ever
known is waterfall - you can buy in the processes that you need. Just be sure that you access a
project management services partner who will get to know and deliver what you need rather than
just the skills that they happen to have in their locker - just doing it differently to how you'd do it
doesn't make it right. Hybrid isn't their way or your way it's a considered, contextual application of
all ways. Furthermore, the right way may change as your project evolves.

Back to Robert Wysocki's PM Times article, "Change is the result of learning and discovery by the
team and, most importantly, by the client. Because change will have a dramatic impact on the
project, only a minimalist approach to planning is employed. Planning is actually done just in time
and only for the next cycle. No effort is wasted on planning the future. The future is unknown, and
any effort at planning that future will be viewed as non-value-added work."

This is not consistent with many in the project management industry's assessment of traditional
project management maturity levels and it's not consistent with the idea that you choose your
methodology from the outset and stick with it. That would be like selecting the little starter fork for
the prawn cocktail and later using it to try to tackle your steak. That could be why Mark Mulally may
have observed that less than 2% of organisations operated at CMMI Maturity Level 3.
It could just be that the other 98% aren't getting it wrong, they could be thought leading the future.



Sources:
https://www.projectmanagement.com/articles/374179/All-Is-Not-the-Same-in-the-World-of-
Project-Management

https://www.projecttimes.com/articles/outside-the-box-forum-what-is-hybrid-project-
management.html

Could disruption be your greatest IT Project opportunity?




I recently re-read the 2018 Project Management
Institute (PMI) Pulse of the Profession report.

I do this every year, reading and re-reading it, over and
over, and each time it seems that I take something
different away! One thing in particular, however, keeps
jumping out and grabbing my attention from the 2018
report.
"Insight 3: Organizations will rely on their project
professionals to take advantage of disruption—not just
react to it."
I think the main reason that this stood out is that, over
the last year, I have had many conversations with
colleagues and clients about how the Project Management as a Service (PMaaS) sector seems to
have subconsciously geared itself up to do just this - to leverage benefits from disruption.

Whatever the maturity of your Project Management operation, to get the greatest results, it is
worth measuring how well it is performing pro-actively in these disruptive times.
Ultimately, there are three ways that organisations seem to deal with disruption...

1 - They try to ride it out and hope that they still have market share (walk down any high street to
see how well that's working out).
2 - They adopt an "if you can't beat 'em, join 'em" attitude (which can trip up even the best - just
look at Google +)

… or the most innovative flip that second option on its head …
3 - They vow to not join 'em, just to beat 'em. They approach disruption as an opportunity to evolve
(and they let their IT Project teams lead).

Disruption IS an opportunity
A good example of this would be Uber's disruption of the taxi industry. Our local taxi firm didn't have
an app before Uber arrived. In the days before Uber you had to call up your local cab operator, often
getting an engaged tone during busy times. You'd have to explain your location to the person on the
other end of the phone and if you were in a strange town this could be tricky - I recall a colleague
visiting Cardiff telling a taxi firm that he was "next to a statue of a man I don't recognise." Post Uber
some taxi firm's apps will even use your phone's GPS position to locate you.
Also, because the Uber software allowed drivers to better optimise their time, capacity utilisation
became an issue for existing taxi firms in order to remain competitive. Time spent in the cab with a
passenger increased with Uber because the platform allowed for better matching of drivers and
passengers. Initially, traditional taxi drivers experienced the opposite, the time that they had a

passenger in their cab declined - until the best firms reacted with optimisation initiatives of their
own.

The most innovative CIOs I know are building organisational cultures that consider disruption as an
opportunity to grow and develop rather than a massive risk or a threat. As a result, they are
expanding their influence within their parent companies. Many are finding that to do this effectively,
they have to look beyond their current capability and resources. They are turning to the Project
Management as a Services market and discovering that the sector is remarkably ready for most
challenges that their teams face from disruption.

Why is PMaaS a disruption Rockstar?

I think this is perhaps because PMaaS exists on the cutting edge as far as evolving tech, tools and
thinking - so it kind of stands to reason that when you live at the sharp end of the good stuff you also
probably encounter the less than good stuff first too. So, you learn to deal with it and turn it to your
advantage earlier than the rest of the industry too.
Another reason may be the opportunistic character of those who inhabit the Project Management as
a Service universe. When you work for XYZ Corporation it is understandable that you just focus on
delivering the goals of XYZ Corporation. When disruptive forces impact those goals, for instance, an
innovation from a competitor threatens to steal market share, it is easy to react in the interests of
XYZ Corporation – I.e., react and respond to the specific disruption and XYZ's unique challenges. In
the world of PMaaS though, the mindset is different - the disruption may be XYZ's but PMaaS talent
instinctively recognises the value of the response to other organisations. Over time, a catalogue of
responses grows exponentially to create a library of value-driven response to disruption.

So, in the case of the taxi apps, an IT project team working for XYZ Cabs might respond by delivering
an app to compete with Uber. Job done! A PMaaS mindset would also address XYZ's need but see
that the tools that they had created could have wider revenue opportunities, like selling the
software to taxi firms across the world, for example. It wouldn't stop at taxis though, so when the
ambulance service is looking for systems that pinpoint callers by their GPS position, by entering the
PMaaS market they could find that a lot of the work they need to do already exists - in the shape of
an app designed to get you home from a night out in town!

Leading incumbents in every industry face the constant risk of being displaced by entrants to their
field using new technologies, new business models, or an innovative approach to capture market
share. It is increasingly important to recognise in advance the potential for disruption and have a
strategy ready to take full commercial advantage of it. As I say our local cab firm didn't have an app
until Uber arrived in the city, by which time the market share horse had started to bolt. In London,
on the other hand, I remember using a taxi app a good year before Uber arrived in the city. It was
clearly a pre-emptive response to Uber's growth in the United States and it meant that this one firm
was ready to compete - if only they'd spotted the wider potential and sold their app globally!
To effectively manage the change, the PMI suggests that organisations focus on the following: -

Prioritise training and development

As project leaders become EVEN MORE pivotal, increasing their training and skills is vital. The most
innovative organisations have seen the value of developing competencies geared towards leveraging
disruption for commercial gain by investing in formal training.

Make it part of your culture - embrace flexibility!

When your organisational culture is set up to view disruptive technologies as an opportunity to
grow, best practices seem to evolve naturally. According to the PMI, eight out of ten innovator
organisations encourage their project leaders to leverage flexible working practices that allow them
to focus on higher-gain work like strategic thinking and planning. The most innovative organisations
not only value the technological shift toward a digital environment, they embrace it!
Seek out new tools and approaches

Digital transformation has always needed an organisation to take full advantage of new and evolving
technology, tools and practices. Organisations that support their project leaders when they consider
a new approach, methodology or process to be right are the ones experiencing the greatest wins. In
Project Management one size has never really fitted all! One of my Project Manager friends is
applying "design thinking" picked up largely from online collateral from Stanford University's
'd.school' - she has the full support of her leaders and is enjoying some innovative results. PMI
predicts the use of new practices, like design thinking, will grow to the same levels as leading current
practices, such as Scrum, Waterfall, Agile etc - that's worth thinking about and acting upon - trust
your talent!

I'd like to add one of my own …
Accept that you are lost - the best solutions and processes may be "out there"

The thing is, disruption is inevitable. Each of these 3 internal improvements thought starters put
forward by the PMI will nurture the innovative leveraging of opportunities that may otherwise be
missed when faced with disruptive technologies. Like any new adventure, it's OK to accept that
you're lost, pull over to the side and ask for directions. As previously mentioned, the PMaaS universe
has been quietly gearing itself up for this moment. It is ready for YOUR challenge.
Remember, I said there are three ways that organisations seem to deal with disruption...

1 - They try to ride it out and hope that they still have market share.

2 - They adopt an "if you can't beat 'em, join 'em" attitude
3 - They vow to not join 'em, just to beat 'em. They approach disruption as an opportunity to evolve
and they let their IT Project teams lead.
Guess which are leveraging the best outcomes from disruption …



Sources:
PMI.org

https://www.pmi.org/learning/thought-leadership/pulse/pulse-of-the-profession-2018

D.school.stanford .edu
https://dschool.stanford.edu/resources-collections/a-virtual-crash-course-in-design-thinking

Cultural fit is not a PMaaS luxury. It's a pillar of your partnership



"As luck would have it, they fitted in perfectly!"

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!

Decisions, decisions, decisions. What IT Project Management Methodology is
best?



Decisions, decisions, decisions. Life is all about choices.
Some are more important than others and choosing the
right Project Management methodology, for instance, is
crucial.

I am often asked what methodology is best and my
answer is always - it depends. Each project is different
and therefore the structures best deployed to deliver
them can differ too.
One easy way to get your head around this is to think of
projects as ball games. Football, rugby, netball,
basketball, handball, volleyball, etc, they're all ball
games, they all share an intended outcome - you want
to win! Each has different rules, tactics, techniques and
practices to achieve this outcome. You would never approach a rugby game with the mindset you'd
take onto a soccer pitch.
The Project Management Institute (PMI) describes methodology as "a system of practices,
techniques, procedures, and rules". They're all projects, they too share an intended outcome -
successful delivery into service. Just like football (soccer) and rugby you will get better results if you
employ different approaches, depending on the project.

Over the coming weeks, I'm going to take a look at individual methodologies and really drill down on
when is best to use each of them. Right now, let's take a fly over some of the most popular and
compare them. If you find that your preferred methodology is not delivering consistent results it
may time to consider some of the others.

The thing is though that human nature often means we are creatures of habit. If you find you are
hard-wired towards a particular methodology, or that it is easier to tread the path of emotional least
resistance and stick with the methodology that you know - you may be short-changing your
potential. If this feels familiar, talk with your Project Management Services partner who can advise
on options that are available that could compliment your in-house facility.
Distilled to their essence, methodologies are processes and guidelines that facilitate successful
completion of tasks. Different methodologies bring different techniques, practices and strategies
and so it is no surprise that each project may benefit from a different approach to your last but each
of the tasks within a project may be better suited to alternative methodologies too.

Here are ... The Four Most Popular Methodologies

1 – Waterfall
Waterfall is among the "old faithful" methodologies, one that many Project Managers consider their
default setting.

When Is It Most Effective? When your larger IT Project has crucial milestones and deadlines, and
when tasks can be clearly defined & sequenced. Also useful for tame projects, i.e. projects that
you've done before and expect to proceed in exactly the same way with no surprises.

A good non-IT comparison is house building! So, in house building, you to need to dig foundations
and build walls before you “top off “. Also, you design the whole thing – from end to end - it would
be a disaster if you didn’t know whether you were building a bungalow, house or an apartment.

What Is It? As the name suggests, Waterfall is a sequential methodology which progresses your
project in a single downward direction that typically delivers at the end. Documentation is key to
Waterfall success, the measure of this is often when a project manager leaves - how easily can his
successor pick up the project? It is a fairly inflexible process but perfect if your project doesn't need
to be agile (if it does, I can think of at least one better alternative).

2 - Agile
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 “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.
3 - Scrum

I've deliberately placed Scrum just below Agile. Many Project Managers don't see Scrum it as a
stand-alone methodology but instead a branch of Agile thinking, Scrum certainly offers more solid
stepping stones to the Agile manifesto.
Scrum is based on the values of ...

•Commitment
•Focus

•Openness

•Respect
•Courage

Whether used alone or as a hybrid Agile approach, Scrum adds to the iterative value of Agile and,
used right, can add increased transparency, governance, accountability and collaborative value.

When Is It Most Effective? Great for mid-sized to smaller teams who need (paradoxically) both
greater flexibility and greater structure.
Scrum is built around key roles. The Scrum Master ensures execution based on Scrum principles, the
Product Owner is the representative of the stakeholders and the Development team who, well,
develop and deliver the product.
Delivery is broken into events, such as sprints, giving a clear and transparent real-time view during
the project lifecycle.

The sprints are at the core of Scrum's success. In "The 5 Scrum Values", Mark C. Layton writes "The
sprint requires clear goals set within fixed time boxes. The good news is, in this model, you break
down those goals into the smallest chunks of work possible so that you know what you’re getting
into. You’ll know what “realistic” is, so you can set appropriate goals and meet your commitments."
4 - Six Sigma

Six Sigma was first introduced in the mid-1980s at Motorola. I believe that executed right, Six Sigma
is the best methodology for eliminating errors and therefore improving quality. Six Sigma identifies
what is working well and more importantly what is not - what is not working can then be removed
from your project's gene pool. Data is key to Six Sigma.

When Is It Most Effective? Six Sigma is great for larger organisations seeking to greater efficiency
and quality.
Proponents of Six Sigma are among the most passionate advocates of any methodology as anyone
who knows a Six Sigma Master Black Belt will attest. Not for the faint-hearted, data is the lifeblood
of the methodology and what you get out of it relates precisely to the quality of what you feed in!
Six Sigma is great for clearly identifying and framing the problem that your IT Project seeks to
address and its goals.

So, that's four of the most popular Project Management methodologies, however, it’s worth noting
that each project may benefit from a different approach, or more likely a combined approach,
applying the elements from multiple methodologies to the task at hand – but more on hybrid
methodologies later.
Look out for forthcoming posts when we can take a deep dive into individual processes and assess
their value. In the meantime, please get in touch and tell me which your go-to methodology is and
why.
Ultimately, which methodology you choose should depend on the delivery value it will bring. The
whole point of your project is to deliver the greatest impact for your business or organisation when
you transition your IT Project into service while deploying all resources you have available in the
most efficient manner possible.

To repeat the question and answer with which we started ... what methodology is best? It depends.

You should never limit your potential outcomes by sticking to your safe, default, "old faithful"
methodology. If you find the best approach is outside your current comfort zone, buying in project
resources, from individual talent to end to end PMO, can help you mix things up and reap the
rewards of doing so.

Sources:
https://agilemanifesto.org/

https://www.dummies.com/careers/project-management/the-5-scrum-values/

How to deal with what wasn't in the IT project handover




Have you ever taken on an IT Project, only to find that a
major challenge either wasn't mentioned in the
handover from the departing Project Manager or, if it
was, it was implicit - not explicit?
It's like those horror movies where a family buys a
house only to find out, after they move in, that it was
built on an ancient burial ground and comes with its
own poltergeist.

As the IT market becomes increasingly talent led, it is
inevitable that more project managers will move on to
pastures new. More and more projects will be
completed by a different manager to the one who took
the brief and set it in motion. Handovers, therefore,
have to be spot on and, often they are not. You can almost forgive the outgoing PM for this. Who
wants to put their name to a document that declares, as they leave, that their legacy is a project that
is out of control?
I once took on a project that was "a tad over budget". Those were the exact words in the handover
notes! What "a tad over budget" actually meant was that costs had crept so far from the initial
forecast that absorbing them would mean drastic re-alignment, there were no contingency funds, so
savings would have to be made by reassessing resources on this project and across the portfolio but,
worst of all, everyone had their head in the sand and denied there was a problem - as you can
imagine, I was "a tad" cross".

Over the years I've heard this story repeated, in one form or another, time and again. If it's not
"engaged stakeholders" who actually turn out to be interfering, then its "proactive team members"
who turn out to be loose cannons. Project Manager handover notes can sometimes be a little like
estate agents’ descriptions of properties where cramped becomes 'compact' and 'double bedroom'
describes a room just large enough for the smallest double bed.

My favourite, by the way, was a handover from a PM who had littered his notes with the wonderful
caveat "in my opinion". I suppose you can fairly describe a failing project as being on track for
glorious success if you prefix everything with "in my opinion." "In my opinion", this guy wrote, "the
team is set to complete a number of key deliverables." Well, in my opinion, England are about to win
the World Cup, opinion and reality are often different things. (By the way, if you are reading this
after the World Cup and England did win it be sure to tell everyone how visionary I was!)
Over the years I have developed two strategies for overcoming challenges that weren't ‘advertised
in the brochure’.
A) Enter each project through the ground floor (Not the Penthouse).

B) Have a plan for everything.

Adopt these two strategies and you'll not go too far wrong. Actually, they are also pretty solid rules
for project management in general. They work not just when you take over a project from someone
else, but also if you are initiating and implementing the project yourself. When you start a project
from day one there are so many unknowns and possible variables that could trip you up ... the
brochure can be equally misleading, vague and lacking in certainty. So, let’s take a look at those
strategies in more detail ...
A) Enter each project from the ground floor (Not the Penthouse)

As demonstrated by the "in my opinion" project manager described above, handovers run the risk of
being subjective. As I say, you can almost forgive the outgoing PM for this, so expect a little
"embellishment" of the reality. Make your own judgement based on the landscape you inherit not
the map of the terrain that you are given.

That's what I mean by entering on the ground floor. You need to start your time on your new project
with an honest appraisal of where the project is at. Consider the example further, if you were to take
the outgoing Project Manager at his word and accept, as fact, that a number of key deliverables
were about to complete, you might start planning from there. This would be entering at the
penthouse – which is all well and good as long as the foundations below you are solid. In this case,
you would have soon discovered that reality was running a little behind aspiration and so the plans
you made were not built on robust foundations, in which event, the penthouse is a pretty precarious
place to be.

Entering from the ground floor, checking the foundations, shoring up work that has been completed
and measuring each stage of the project against your high standards, not someone else's, although
initially time-consuming, is worth it in the long term. Plus, it gives you ownership and a chance for
the project team to start with a clean sheet and make good any corners that were cut or mistakes
that were made - interview them, run over the handover, canvass their viewpoint. You're not
starting from scratch, but you can quickly stamp your mark on a project by doing this.
B - Have a plan for everything

This works whether you are taking on an existing project, starting a brand new one or, when you are
parachuted in to rescue a struggling project. Back in my early days of Project Management, this
meant copious note taking, making sure that I learned and remembered lessons from previous
projects and a cultivating a trusted squad of contacts I could call on to help from my address book.
Having a plan for everything meant drawing upon my experience and it served me well for many
years. But it was also limited. I hadn't experienced everything! Then, something game-changing
happened.

Project Management as a Service
A universe of possibility opened up. You could draw upon the experience of others and a huge range
of possibilities that hadn't even happened yet. The project I mentioned earlier, that was "a tad over
budget", delivered on time and within cost. It was thanks to resources accessed from the PMaaS
market and at a lower cost than the internal resources already allocated which could be
redistributed across the portfolio and put to better use.

These days there really is no excuse. There is always someone who will help, either after a Google
search for projects that have faced and overcome the same challenges you are facing or by
developing a great relationship with a PMaaS partner who will always have your back.
Having a great PMaaS partner also gives you some protection from talent moving on. Having an
independent third party “in the background” allows you to enjoy continuity by keeping the lights on
during periods of staff transition. PMaaS solutions can be dialled up or down in line with demand
and a great partner will get to know you and your projects as well as you do.
However, you are coming at your next project, inheritance or initiation, entering through the ground
floor and always, ALWAYS, having a plan, will see you right, regardless of what anyone "forgot" to
tell you!

How to marry business strategy with IT Project Management and why you

must



I've written about the need for business strategy and IT
projects to be aligned before. I can summarise the
thrust of all the articles that I've ever written on the
subject with two words - it's critical. I mean, otherwise,
what’s the point?
Yet, many IT Projects get greenlighted without sufficient
business need and many others, that meet key strategic
requirements, get mothballed or cancelled. In the case
of the former, sometimes organisations confuse "nice
to have" with "must have", and in the latter, IT teams
sometimes simply fail to make the business case
strongly enough.
Increasingly though I'm spotting a different trend
emerge. For some IT Projects, business case is just REALLY hard to quantify.
Take these three IT Projects that my colleagues and I have recently helped to bring to life in one
capacity or another. Which do you think was the easiest to prove business case for and which do you
imagine was the hardest?
Project A - Key goal - Increase system reliability.

Project B - Key goal - Increase productivity and reduce cost of business processes.

Project C - Key goal - Improve customer service through interactive point of sale touch screens.
Most people I have asked believe Project B was the easiest. They are, of course, right.
Demonstrating business case for Project B was like shooting fish in a barrel! Increasing productivity
and reducing costs, especially when you can quantify both, are such obvious business wins. They're
so tangible! The board, busting with enthusiasm, couldn't wait to sign this one off.
Project A and Project C, on the other hand, were harder business case sells. The customer service
improvements delivered by Project C were hard to quantify but the system reliability project was like
pulling teeth! In fact, Project A got turned down three times before, eventually, a convincing case
was made.

So, in terms of obvious business benefit, the projects ran B, C, A in order.
Now, can you guess the order in which the projects would rank if the criteria were actual pressing
business case? If you had to rank the projects based on how critical each was to organisational
strategic goals - in what order would you list them now?

Interestingly, in these terms, the projects run A, B, C.

Note that the most critical project was the hardest one to prove a business case for. It was also the
one that kept getting knocked back time and again. This highlights the challenge that IT teams are
facing.
As we consider the solution to this challenge, let's first nail what business case actually means.

I like this definition. In "Making Technology Investments Profitable: ROI Roadmap to Better Business
Cases" (Keen/Digrius, 2002) business case is described as a “justification for pursuing a course of
action in an organizational context to meet stated organizational objectives or goals.” To be fair, this
is roughly the definition used by most when either pitching (or assessing the need for) an IT Project.

The organisations that greenlighted Projects B and C had an easy job. After all, which business
doesn't have a stated organisational goal to increase productivity and reduce costs!? The business
that gave the nod to Project C has an almost 'Steve Jobs-esque' passion for delivering end-user
satisfaction so, for them, an IT Project to improve customer service was also something of a no-
brainer.
BUT, what about Project A?

Let's be honest. No-one has ever raised their hand at a meeting to put together an organisational
mission statement and suggested "system reliability" as a key pillar. You don't walk into a business
premise and read "system reliability" among the lofty goals painted in huge letters on the wall above
reception and I don't think I've ever heard the words mentioned in radio or TV ads or in straplines
beneath a company name on a van. To return to the Keen/Digrius definition, "System reliability" just
isn't ever a stated business goal!
Without "system reliability" though, all your actual goals would collapse like a house of cards!

To you and I working in IT, this is obvious. You see the day to day business value that your IT
infrastructure adds because you live it and you breathe it. It's actually a huge tribute to your skills
that others in your business don't see this value straight away because it means that your IT is
quietly and efficiently going about its business. Believe me, it's usually when the board knows you
exist that you're in trouble.
So, when you believe that a project has legitimate business value you have to find the best way to
demonstrate it! This means REALLY thinking about your pitch from the perspective of the business,
the board and the managers who run the departments it will affect - and putting the business case,
explicitly, in their terms.

This is what happened with the IT team seeking a green light for Project A. The business had enjoyed
greater than forecast sales growth and to an experienced eye, the IT systems that delivered the
growth were starting to creak (but still working well). What's more, from an IT perspective, business
departments were operating as silos (and this was hampering further growth). So, the first pitch had
landed on deaf ears because "improving system reliability" just didn't grab the attention of the
board, the second (this time focussing on the departmental separation of IT systems into silos) was
dismissed too - they just didn't get what that meant.

It was only after a major reframe that the board sat up and listened. The third pitch was slightly
more apocalyptic! It focussed on the business consequences of not improving systems, it spelt out
the cost and likelihood of downtime, the dangers of siloed IT systems not working together when
stretched beyond their original designed limits and finally, on a more positive note, it outlined the

growth that the improved, integrated systems would safely accommodate. This time the project was
signed into life.

The value of business case/IT Project alignment lives on beyond the pitch and subsequent green
light. There's a frisson of excitement around Project A now that it is live! Stakeholder and end-user
engagement are critical to the success of an IT Project and in the same way that your board buys in
when a project is pitched from their point of view, so too does everyone else along the lifecycle! As
an IT user, if you tell me that systems are going to be down to improve "system reliability" I may roll
my eyes at you but if I understand the benefits that your work are going to bring I'm interested.

The IT team working on this is more buzzed as well! Being honest, maybe they weren't as passionate
in those first two pitches as they were in the third. Think about it, improving system reliability and
knocking down silos are worthy endeavours, but they don't set the world alight! The way the third
pitch was delivered makes the IT guys feel like saviours of their company and its future! They have a
real purpose as they go about their work developing and implementing the project - what they are
doing really matters!

And in conclusion, that's what matters - that it matters! Folks buy in when they can see and feel the
value!

When there is no connection between your business strategy and your IT Projects, or when business
case exists but is not clear, project failure risks increase, measuring success is harder, accountability
is blurred, and enthusiasm can quickly evaporate.

If you need help aligning IT Project ambition with your business need, often working with an
independent third party, like a trusted IT Project Management Services partner can see connections
and opportunities that you may have missed. After all, you work in your business day in and day out
and so do we.
When alignment between business strategy and IT projects is explicitly defined and clearly
established, even if all you're doing is improving system reliability, success becomes easier to
measure and to achieve.




Sources:
https://www.researchgate.net/publication/234815653_Making_Technology_Investments_Profita
ble_ROI_Roadmap_to_Better_Business_Cases

How to rescue a failing IT Project - and when not to




A significant number of IT Project Manager friends have
reported shorter times between going live with a
project and that project running into trouble or starting
to fail. This means that they have to be on their mettle
from the get-go and bring all their experience of
rescuing a project in to play a lot earlier than usual – no
honeymoon period!
I'm happy to report that all but one of them did rescue
their project, either using their own years of knowledge
and wisdom, getting advice from a trusted partner or by
calling in help from the Project management as a
Service market - where help is always on hand!
Interestingly, the one who didn't rescue their project
actually "strategically failed" - more on that later.
The debrief following projects that go AWOL can be very revealing and the lessons that can be
learned could save your project in the future so, with that in mind, the Project Managers behind the
above success stories and I have put our head together to compile a Project Recovery Tip List - it's by
no means exhaustive and I would love to hear any additions that you have - please do get in touch!

1 - Prioritise

When a Project starts to fail you can be faced with a number of apparent contributing factors. It is
crucial that you know what to deal with first! It's all too easy to get busy sorting out something that
may not make much difference to your project's outcome.

Often a 'glaringly obvious cause' of failure can actually be a symptom of something else bigger that
really needs attending to. A Project manager friend always tells the story of houseplant he had that
had leaves that kept turning brown, he watered the plant, fed it and spent a small fortune on leaf
care products but to no avail and then one day he caught the dog using the plant as a toilet. When a
project fails it's all too easy to attend to the obvious - take a step back and take a second look before
ploughing all your energy into what you see first.

TOP TIP - Always refer to your project’s goals and scope when assessing what to attend to.
2 - Consider reassessing your goals

Are the goals you set out with realistic? Often the problem with a project is that its goals were way
too optimistic and it can, sometimes, take initiation to realise this! Scaling back goals is an awkward
conversation to have but sacrificing some 'nice haves' to protect the main strategic business reason
for the project is hardly a sacrifice at all.

3 - Do it now, do it brilliantly

When your IT Project slides towards a fail what you do next, how you react is key! Having
established what you need to do speed is of the essence, but you need to ensure that you are
thorough in your execution. This is real 'A game' territory - anything less than 100% will not make
the grade.
I love Moira Alexander's CIO.com blog on this. She says, "Assign resources to address priority
concerns. After identifying issues and their impact, resources can be assigned to address your
prioritized concerns. Make quick yet methodical changes to realign the project activities.
Communicate the changes to all necessary stakeholders to ensure everyone is on the same page."

Sometimes, you may find that you don't have adequate resources to address those concerns - the
quicker you make that assessment the sooner you can enter the Project Management as a Service
market to bolster your response.

4 - Monitor like you've never monitored before

My PM friend Sue says that as soon as she identifies that a project is in trouble it gets placed in
'special needs' and it doesn't come out until the project is delivered or delivery is 100% guaranteed.

This doesn't mean breathing down the necks of her team, but it does mean that she demands even
greater transparency, governance and reporting. It also means a constant re-evaluation of priorities.
Once issues have been satisfactorily attended to, you must reassess your project’s priorities and
document your findings to avoid unnecessarily repeating work - your time, talent and resources
have become even more precious commodities - you have an extra responsibility now to monitor
their allocation.
Also, once you believe your project is back on track you need to have a regular routine in place for
monitoring all your project commitments to make sure the wider portfolio is not affected negatively
by the work you had to do to bring this one back on track - it can be like plate spinning!
5 - Be honest - Is the project worth saving?

Too often, pride plays a major part in deciding to rescue a project. No-one wants to be associated
with a failed project but if a project is not going to deliver the intended business outcomes or those
outcomes are no longer relevant, then tough choices have to be made based on a commercial view.

Remember I mentioned that I was happy to report that all but one of the failing projects that had
appeared on my radar were rescued and the one that wasn't "strategically failed"? This was a
project that, having got underway, had soon been rendered commercially and strategically less
valuable by the actions of a competitor. The blip that flagged this the project was off-course was
actually a blessing that allowed the team to fully take stock and agree that although it could be
turned around - there was very little point in doing so.

Hopefully some food for thought there. I think that the greatest thing that you can do when an IT
Project slides into trouble is talk - you know what they say about a problem shared!? The quicker
that you are transparent about a problem the faster you can get to sorting it - so talk! Talk to team
colleagues, stakeholders, sponsors and because, more often than not an external pair of
independent eyes can see things that you have become blind to, talk to your trusted project
management services partner.

Hybrid projects – name a project that isn’t?




Guest blog by Andrew Gallagher – Principal Project
Manager

Working on projects for a long time, longer than I care
to remember, the same topic just keeps rearing its
head.
Be it in the public or private sector working on IT or
Business Transformation the same question comes up
time and time again.
What am I referring to? Well in a nutshell, how are we
to run our projects?

For those of us who go through the 5-year (or soon to
be 3-year!) cycle of PRINCE2 re-certification we’ll be
reminded of (what we know anyway) you must tailor your project to fit with the
company/organisation you’re delivering for.
But it’s not really that simple, or is it? I think as an industry, change practitioners are guilty of falling
in the trap of slavishly following a given PMO framework at the given employer. This gives a PMO a
consistent metric to track against but for change delivery following this doesn’t fairly reflect the
breadth or depth of change coming through in this information age.

Some projects/programmes are heavily regulated to a point where a good old PM becomes more a
process manager than a PM. Others, typically newer PMO’s, are more of a free for all where people
come in and help out with a sense of priorities but work first on who shouts loudest.

All this theory aside on how projects/programmes come into being, the core reasons for doing a
project still should stack up:

1) Is the scope known? Can a sponsor say to you, as a PM, what they want from your project?
2) Do we have a business case (or at least a mandate) which demonstrates benefits which
everyone can agree to? Does it tick all, or at least some, of the key measures (Specific, Measurable,
Achievable, Realistic, Timely)? We all remember the courses and presentations taking about being
SMART but it’s as valuable today as it ever was.

3) Is there a team in place to deliver it? Sounds obvious but often projects are initiated without a
team agreed which creates a stack of work which doesn’t get beyond initiation and analysis
paralysis.

But the $64k (or sometimes multi-million dollar) question is how, as change practitioners, do we go
about delivering our projects?

Well, there is no one answer, and I think that’s the point really. What we can do though is don’t box
ourselves in.

We can though have a great approach, think Hybrid:

1) What is the appetite in your company/organisation for Waterfall vs Agile can you mix it up?
Apart from building rocket ships or doing 100% software product development, you’ll struggle to
work in your career on out and out Waterfall or Agile projects. Therefore, it’s perfectively
reasonable to propose to do a bit of both when it suits.

2) If you find yourself having to explain or justify to a sponsor why you’re using Waterfall or Agile
you’re (in my humble view) doing it wrong. I’m terrible at plumbing, much to my wife’s chagrin, so
when my local plumber comes along to fix my loo, I don’t ask them what method they’ll be
deploying to fix the flusher (is it even called a flusher?!) I just want to know how long, how much and
they will not leave a mess. Why should a project be any different?

3) Focus more on a product and less on a project. As a PM I consider the project to be my baby to
nourish and grow and own, it’s a living thing which I need to look after, beyond me though in the
business world it’s delivering something that has a product at the end. If it doesn’t why are we
doing it? Again, the how we do it part is less something to get hung up on and having to explain, to
reference the previous point.
4) Delivering the product is the single most important factor, we could have what is considered a
brilliant change methodology but if it doesn’t deliver, no-one is going to thank you for having a
wonderful PMO process which ticks all the governance boxes if you can’t get product out there.
In summary, what I’m saying here is be more focused on what your sponsor wants and worry about
explaining the method later.
Within a high performing team, I’ve worked with we had a motto GSD - Get Stuff (or replace with
something more choice!) Done, rely on your experience and judgement to make the right calls to
deliver our projects.
Project Management as a Service (PMaaS) can be an option to look at to cut through the smoke of
method vs Delivery offering experience and practicality to help your PMO deliver great projects and
to GSD.