Straight Talk On Project Management - Volume III

Straight Talk On Project Management





















ABOUT THE AUTHOR

David Cotgreave MBA, BSc (hons), PRINCE II, brings over 20 years of experience in Programme
Management, Consultancy and IT Leadership, not only to this next edition but to his current role
at Stoneseed Ltd, a company he founded in 2009. The company offer a unique proposition -
Project Management as a Service (PMaaS).

This third volume of blogs continue to reflect his passion for PMaaS, while remaining light-
hearted, funny and covering all things Project Management. David continues to produce
insightful and informative blogs for Stoneseed’s avid 5,000+ readership. He is also regularly
published on CIO.com, ProjectManagementworks.com and other industry publications.


ABOUT STONESEED

Stoneseed was founded to provide our clients with well qualified advisory, delivery and
management of their IT projects. Critical for us at the outset, was that all our services should be
truly independent, objective and we remain agnostic of all technology vendors.

Project Management as a Service (PMaaS) provides access to a wide portfolio of project skills,
from single Project Managers, right through to a large team of fully utilised project professionals
- Programme Management, Project Management, Business Analysis, PMO and PSO resources.

Stoneseed’s highly flexible and resource on-demand model allows you to dial up and down IT
project resources in sync with your delivery needs.



Contents


Chapter One: Developing the qualities of a great PM

Chapter Two: Leadership

Chapter Three: Developing the PM team


Chapter Four: Best Practice
Chapter Five: The PMO


Chapter Six: IR35



Straight Talk On Project Management



Chapter One – Developing the qualities of a great PM





WISE WORDS


"Let our advance worrying become advance thinking and planning." ~ Winston
Churchill

"Plans are worthless. Planning is essential." ~ Dwight D. Eisenhower

"The major reason for setting a goal is for what it makes of you to accomplish it. What it
makes of you will always be the far greater value than what you get." ~ Jim Rohn

Are you passionately curious? It's IT Project Management's success secret,

and size matters



Why do some projects stir a passion within you and
others leave you less revved up? Could unlocking the
secret lead to fewer IT Project failures?
It's true, isn't it? The more passionate about a task you
are, the more likely you are to succeed. Even doing the
dishes can be a chore or a fun twenty minutes
reviewing the day with a loved one. Same with IT
Projects!

I've been involved in some REALLY exciting IT advances.
Don't get me wrong, I've always brought my A game
and been REALLY proud of the delivered project and
then, strangely, found myself getting EVEN MORE
excited about the next project that had a less 'headline
grabbing' outcome. I know I'm not alone because a friend just emailed to say that of the two
projects his team were handling, a 'sexy new app' and a 'keep the lights on' system upgrade, he was
more excited by the latter. What's that all about?!
I've often been asked what it is that gets IT Project talent out of bed in the morning. What drives us
to search out seemingly hidden meanings in oceans of project data? What spurs us to burn the
candle at both ends, to pull late nights and long weekends to miss nights out with friends and nights
in with the other half? I've also often joked that if we could work this out, bottle it and sell it - we'd
be millionaires! So, let's have a go at this.

By chance, recently, I happened across a concept that I first heard about in the 1990s and which, I
think, may hold the key to why some projects inspire more than others. The information gap theory
of curiosity.

The information gap theory of curiosity was developed by Professor George Loewenstein of
Carnegie-Mellon in the early 90s. Essentially, Loewenstein believes that curiosity can be boiled down
to the emotional reaction you have when you identify a gap between what you know and what you
want (or need) to know!

Einstein once remarked, "I have no special talents," adding, "I am only passionately curious." Was
Einstein on to something? I think that this "passionately curious" tag applies to everyone in IT
Project Management most of the time ... but not always! So, why are we more "passionately
curious" about some projects than others?

It could be that size matters.
I'm not thinking about the size or complexity of projects, although it is sometimes nice to have a big
meaty project to sink your teeth into - that's not always enough to spark a PM's passion. Thinking
back to Loewenstein's theory, could it be that how passionately curious you are about a project is

directly related to the size of the gap between what you DO know, and what you NEED TO KNOW to
deliver it?

Paraphrasing Loewenstein, we tend to be more curious about things when we feel close to the
answer ... but not quite there. Therefore, if you feel that delivering a project is a walk in the park,
you may be slightly less animated working on it than on a more cerebrally challenging project, even
if that project's outcomes are less likely to set the world alight!
Similarly, extending Loewenstein's theory in the other direction, where a project is totally and
utterly beyond your current capability and experience - it's maybe even easier to see how you might
fail to keep up a sense of passionate curiosity when the information gap is too great.

Talking recently on a Radio 4 documentary about (of all things) Mars, Professor Loewenstein
remarked, "People tend to be most curious when they know a lot about a topic but there's some
kind of salient question that remains unanswered. That’s sort of a sweet spot for curiosity. If you
don’t know very much about something you don’t tend to be curious and of course, if you've
answered the question, you're no longer curious - because you have the answer!"

So, this could be why you get passionate about some projects and others ... well ... not so much.
When a project tests you, challenges you and wakes you in the night with 'eureka moments' but you
know that delivery is within your capability, you are much more likely to apply your curiosity muscles
to it than when you're way out of your depth, or coasting to a hassle-free delivery.

As Loewenstein says, "The perfect gap is where you know a lot but there's still a well-defined
unanswered question. In the case of Mars there's a lot of questions but certainly, the number one
question is whether there's life there or has been life on Mars in the past. It's a very ... salient
information gap for a lot of people."

That salient gap may be the key!
I suppose when you know a lot but not quite everything you can, with some confidence, fill in the
gaps from yours or your team's knowledge bank. You fill in gaps with hypotheticals, informed
estimations and experience led guesswork. That must also drive curiosity ... you want to see if you
were right (even though you're pretty sure you are because you made the call with the safety net of
past success). The larger the information gap the more any guesswork becomes less of a calculated
risk and more of a gamble.
Thinking about all this, I am wondering if the information gap theory of curiosity could be the root
cause of problems with most failing projects, that I am asked to consult upon and attempt to rescue.
I mean, I have seen projects where complexity and size are way beyond the experience of those
tasked with delivery and failure could (and should) have been predicted, but there also projects that
fail where you'd think that successful delivery was WELL within the team's capability. It's a bit like
when a league leading football team beats everyone in the top half of the table but loses against the
side fighting relegation.
I think that we have stumbled upon something here but how do you apply the information gap
theory of curiosity to IT projects? What can you do when you risk either complacency because a
project is too safely in your comfort zone or wild guesswork when it's way, WAY outside? The regular
reader will expect me to point to Project management as a Service for the solution and I'm not about
to disappoint. After all, if there's one thing that I am passionately curious about it is the ever-
expanding universe of answers that is the PMaaS market.

It might be obvious to point to the big information gap projects as candidates for patching in PMaaS
talent and resources, but I'd also suggest that projects at the other end of Loewenstein's thinking
might also benefit. Is your in-house talent best deployed on an "easy" project, or would they be
better somewhere else in your portfolio? PMaaS can free up existing talent and resources who are
working to keep the lights on so that you can allocate them to a place where being passionately
curious might have a greater impact.

So, there you go. Something I heard about in the 90s and stored in the back of my mind piqued my
curiosity in 2018 and presented a possible secret to success! I'd be passionately curious to hear
about any information gaps you have in your project portfolio and even more passionately curious to
see how we could help fill them.

Fail fast, fail often, fail well: The key to IT project success



“I've missed more than 9000 shots in my career. I've
lost almost 300 games. 26 times, I've been trusted to
take the game winning shot and missed. I've failed over
and over and over again in my life. And that is why I
succeed.” – Michael Jordan.

An IT Project Manager I know, let's call him Richard, has
just had the biggest run of bad luck that I've ever seen
while delivering an IT Project. You know those online
lists of things that can sink a project? Well, Richard's
project has checked them all off one by one. It's been
enough to consider throwing in the towel on an almost
daily basis, there was "sign" after "sign" that luck wasn't
with him. Many other PM's I know would have given up,
many other CIOs would have pronounced the project dead and a drain on resources - it did look
holed under the water line! The problem was that this project added key strategic value, the
business case was indisputable and future projects were entirely dependent upon it.
By the way, that quote from Michael Jordan is from a poster in Richard's office.

This week, Richard delivered his project just a week and a half late and only a fraction over budget.

Richard, the unlucky Project Manager, doesn't even see himself as unlucky! He relishes the challenge
that failure brings and the opportunity to learn and try something new.

The truth is that most successful people have more failures than average because they do more.
They ideate more, they try more, they challenge themselves more. When it goes wrong, they pick
themselves up, and dust themselves down, they learn the lessons that failure has taught and shake
off negativity quickly. Contrast this with others who dwell on the mistake too long or commit to
make the failure the last thing that they do in the project and it's easy to see how response to failing
is the difference between victory and defeat.
I've always maintained that once a goal is clear you cannot let 'failure' and distractions get in the
way. You cannot be swayed by criticism or what people "want to hear" – you have to stick to your
guns - never stop at a failure, keep going until you get all the failures out of your system until the
only possible outcome is success.

I love the quote from Thomas Edison about his "failure" to invent the light bulb. “I have not failed
10,000 times," he said, "I have not failed once. I have succeeded in proving that those 10,000 ways
will not work. When I have eliminated the ways that will not work, I will find the way that will work."

Smart man Edison! There could be a lot in his mindset for Project Managers. Moving quickly to prove
that an idea is not going to work, allowing you to side-line it and shift focus elsewhere can only
speed up success, right? So ... how to apply it?

Here are Four ideas on how to Fail Fast, Fail Often, Fail Well.

1 - Ask an independent external pair of eyes to take a look

Working hard in your project, it can be hard to spot when things go off course, take a view on what's
going wrong and what to do to correct it.

Often, a trusted IT Project Management partner can walk into your project and instantly spot things
that you have become blind to and advise timely corrections.

One of my PM friends compares this with the home improvements that he made when he sold his
last house. He'd lived there for seven years and there were a few jobs around the place that he'd
been ‘getting around to’. One, in particular, was that he had installed the wires for a shaving light
above the mirror in the ensuite bathroom, but never bought the light! Over time, he had become
blind to the wires hanging out of the tiled wall with their ends sealed with coloured insulation tape.
Every potential buyer saw them though and couldn't see past the protruding wires to take in what
was an otherwise show-home quality bathroom.

2 - Get good at quick action evaluation
When an IT Project takes a wrong turn and you take corrective actions - how good are you at
measuring the effectiveness of those actions?

Many IT Projects flounder not because they fail to identify an initial problem but because they fail to
monitor how well their interventions work.

A PM friend, Martina, implements a great 'measurement cycle'. Firstly, she believes that 80% of
solving a problem is becoming aware of it and having the willingness to tackle it! At this stage, she
says, the hard part is over, so she treats her team to cakes or something like that as they
gather to work out the solution.

At this meeting, the team is encouraged to believe that they are free to ideate, they are not trapped
by preconceived ideas or 'what's worked in the past'. At this stage, the mission is to increase
potential with extremely positive, empowering language and thinking. This freedom allows some
really creative solutions to be suggested, like seeking ideas from the Project Management as a
Service sector. Martina considers this stage to be about 15% of the overall process and it is here
where the real genius lies.

95% of the work is done. The pressure is now off!!

The corrective action and measurement of the success of that action are only 5% of the total process
effort, 1% for the action and 4% for analysis of the result of the action!

Firstly, this allows the team to move bravely forward and implement the action - and be totally
honest about how well it has worked.
Secondly, and this where the "cycle" part comes in, the team is encouraged to evaluate quickly and if
necessary get back to the start of the process again where awareness and willingness kick-start any
necessary further actions.
3 - Pre-mortem beat post-mortem!

You'll have heard of, and probably, done a post-mortem where you look back at a project after it has
failed to find out why.

What if you could predict in advance why a project is likely to fail? (Google) X's Astro Teller often
talks about pre-mortems. At X, teams vote to kill their ideas in advance - pre-mortem. The thinking
being that the ideas that survive this process (those ideas you literally can’t kill) are the ones worth
pursuing.
I have seen this work really well in IT Project Management where the Project Team have emailed
stakeholders and end users, explained what the goals of a project are, how it will work, what it will
deliver and then asked ... "A year from now, this project has failed - why?".
The feedback the team got from this was invaluable. Once they had identified and filtered out the
change-resistant negative gripes, they were left with some really useful insight that undoubtedly
allowed them to "see around a few corners".
4 - Get good at flagging up issues

When a culture evolves where everyone has the right AND the responsibility to flag potential issues
it's amazing how much more quickly they are dealt with, accelerating success.
The textbook example of this is Toyota's 'Stop the Line' manufacturing technique, in which every
assembly line employee has a responsibility to push the big red button that stops everything when
they notice something that they are not happy with. When this happens supervisors rush to the
source of the issue and the first thing they do is thank the employee who pushed the button. By
fixing problems as they happen what you maximise your response options and improve your
process.
Too many IT Projects still have a culture where you press on and anything less than full steam ahead
is not acceptable. Sometimes, most times, you get there quicker by occasionally stopping to check
that you're on the right route! Taking a helicopter view once in a while and encouraging all team
members to holler if they feel that something isn't right has saved many projects from costly
problems.

That's just four thoughts on how to, as the title says, "Fail Fast, Fail Often, Fail Well". As the second
half of the title says, "The Key To IT Project Success" is in how well you fail so I would love to hear
any thoughts or any tricks that you have and, as always, if YOU need that independent second pair
eyes, please get in touch.

Five shortcuts to managing IT Project stakeholder expectation



I've noticed a bit of a trend. Of the IT Projects that I've
seen fall into ‘special measures’ of late, they've all had
something in common - a gap between stakeholder
expectation and reality.

It's actually (paradoxically) both easy and hard to nail
this. Some project teams struggle but, like with most
things, you just need someone to show you how and
from then on, it's easy! I believe with a little effort you
can ensure that EVERYONE involved with the project
knows what to expect and when.

Five shortcuts to managing stakeholder expectation


1 - Plan the journey together before fixing on an eta

One of the first questions a lot of clients and stakeholders ask when you meet to discuss a project is
"What will be the delivery date?"
Would you plan any other journey like this? I mean if we decided to travel to Buenos Aires - how
accurately could you predict an ETA? You wouldn't take a guess before breaking the journey down
into its different parts, would you? You'd have to work out which airport to fly from; what time the
departures are and how long the flights are; how to get to the airport and how you get from the
airport to your destination at the other end.

Too many IT Project delivery dates are agreed without due attention to the tasks and milestones
along the way. Like our journey to Argentina, break down the project into chunks and agree on
scope and delivery timetables based on proper measured thought.

Funny story, back in the day some friends of the family who are London based Arsenal football fans,
set off for an FA Cup tie in Wrexham. It was the days before Satnavs and the task of planning the
route was left to an uncle. It was a good hour and a half into the journey before they realised that
the route, he had planned was taking them to Wroxham in Norfolk rather than Wrexham in North
Wales. The moral is that proper journey planning may take a little time up front, but it will pay back
later with accurate timescales and clearly defined and agreed expectations.

2 - Your plan - KISS

KISS - Keep it Simple (for) Stakeholders
What this means, in essence, is don't overcomplicate documentation and plans. I recall a project
where the team detailed each task within the project, each milestone, in microscopic detail. The
business stakeholders didn't care about any of this, they just wanted to know when the project's
deliverables would be transitioned into service and when they would start seeing a return on
investment (ROI). This vital information got lost in the noise and the stakeholders created an
unrealistic expectation that was different to what the project team had been trying to communicate.

The project delivered in line the project team's expectations, on time, on budget and delivering the
business change promised but it was not within the false expectations of the stakeholders. This
resulted in the project team having to engage in some pretty awkward conversations with
disgruntled stakeholder clients who had misunderstood the over complex planning documents. You
know the adage, "The customer is always right"? Having to tell them that they're not is never easy –
especially when it’s kind of your fault they got the wrong end of the stick. K-I-S-S!

Avoid this by playing to your audience, deliver it in their language. If, as in this case, your
stakeholders are business minded, deliver your plan to show you clearly understand business need,
expectations and requirements. Ensure that they are documented in a way that cannot be
misunderstood in your scope statement. Less is more!
3 - Keep it REAL

Realistic Expectations Allowing (for) Lag

When planning, you work backwards from project delivery and work out timings for tasks. You add
these timings together and that gives you your project lifecycle. OK, that's a little simplified but
that's pretty much it - but what happens to your project and by default your client or stakeholder
expectations if something goes wrong?
The most successful project leaders and CIOs allow time in their project timelines for 'eventualities'
and conflicts.

Say the project's task add together to five months, rather than agree five months with your
stakeholder and communicate that to your team push for six or seven months. If the team delivers
the project in five then they feel like rock stars, their morale is lifted, and you get to carry that
confidence onto your next project and the best bit - your stakeholders think you're the best because
you delivered with a month or two to spare.
Keeping it REAL requires being mindful of business needs and pressures. I mean, don't take the
mickey, if the project needs to deliver to market in five months to compete with a rival, then it’s in
your interests to bust a gut to achieve that.
BUT if you can buy some time it's a very wise investment.

4 -Update, update, update

The most important part of setting and achieving milestones isn't that you've set and achieved
milestones. It's that you have communicated them with your client.

Many project teams see milestones as internal progress markers but actually, they are crucial for
managing client and stakeholder expectations too.
If you hit the first few milestones late but advise your client, you can either assure them of steps that
you'll be taking to catch up or begin to prepare them for later than planned delivery.
I was on a train recently that was a minute late leaving the first station, two minutes at the second
and so on. The Train Manager announced each delay with an apology but what he failed to
communicate was the impact on our final arrival. A near riot was about to ensue among passengers
as they speculated and advised those collecting them from the station that they may be late. Then
the guy explained over the loudspeakers that despite delays along the route we would arrive at our
destination on time (the train companies are very good at point 3 and pad their journey times to
avoid fines!!).

A final word on the bit about updating. Be honest when things go wrong - when it comes to
managing expectations nothing beats the truth and the goodwill that this honesty generates
(almost) always buys you some understanding should you hit further issues along the way.
5 - Pick your best team

It's amazing how far a client's or stakeholder's confidence in your team goes towards how they
create their expectation of your capability to deliver. Breaking down tasks and knowing who, on your
team, will perform them best and knowing who will work well together when required is a real skill;
the better you become at it - the better your team will become at delivering successful, high quality,
business case led projects.

If you identify a capability gap the Project Management as a Services market has an abundance of
resources ready to plug straight in - so don't feel that you have to chance it. Allow me one last
football analogy? It's like the difference between when a football manager fields a weakened team
in a cup tie and they get hammered and knocked out of the competition, and when a manager fields
his full strength team and they scrape a win. The benefit of the doubt from the fans is far more likely
to be forthcoming following the latter scenario - and so it is with stakeholders of IT Projects. Always
field your best team (and that includes drafting in external resources if you need to).

In conclusion, managing setting and managing expectations can be one of the hardest things to get
right in IT Project Management but it’s also one of the most rewarding. Making sure that EVERYONE
is always on the same page should be a priority for us all!

If you have any thoughts, ideas to add or you need some help with this in your projects, I EXPECT
that you know how to get in touch.

IT Project Perception and how misuse of '&' really lets you down



Guest blog by Nicol Cutts – Stoneseed Head of Projects



I reviewed an initial project scope document for a
Project Manager last week. In the four pages of text,
there were 37 ‘&’s.

So what?
'&' or the ampersand is often misused and
misunderstood. Largely thanks to social media
communications, where you are limited to a maximum
number of characters, this misuse is fast becoming
something of a trend.

Again, so what?
I asked ten IT Project people to share what they knew of ampersand. One nailed it, eight out of the
ten said it was short for 'and' - and one hilariously answered, "Isn't it in Norfolk?" I think (hope) that
he was joking. Although to be fair, Ampersand does sound like somewhere you'd take the kids
crabbing on the North Norfolk coast!

Is it a worry that nine people I asked didn’t know that usage rules exist? I mean, if nine intelligent
people surveyed don't know the rules, then surely that means that 90% of readers won't know
either so they won't notice. Surely?

Hmmmmmm. Maybe not.

To Susan, a CIO friend, "ampersand abuse" is a pet hate and a real ‘nails down the chalkboard’ issue.
Susan wrote to me recently, "If you wrote up project documentation and substituted ‘and’ with 'n',
as in rock 'n' roll, you'd have no credibility at all! To me '&' is the same."

When put like this, you do wonder why project managers take the short way out? What’s wrong
with writing “and” - if "and" is what you mean?

"If a project manager can’t write a document correctly, what else are they doing to take the easy
way out," added Susan.
The first thing about ampersand is that it doesn't necessarily mean 'and'. Here's a handy dictionary-
style definition.

Ampersand: a stylized, contractual form of the Latin word "et". Although the Latin word "et" does
mean "and", it is improper to substitute "&" for "and".

Many people incorrectly substitute this symbol for the English word "and".

Ok, but again, SO WHAT?

Here's why I think it does matter.

1 - It's a short cut. As IT Project Managers, a big part of our job is to find short cuts to expediate
delivery or reduce costs. It is important, I think, that we convey the impression that we know which
short cuts to take and when. Do pages of misused '&'s do this? I'm not sure it does.

2 - Another huge part of what we do is methodology. The CEO, the Finance Director, the whole
board at most companies that I have dealt with do not understand the rules of Agile or Waterfall or
any IT Project methodology that you care to mention. When greenlighting a project, however, they
are saying that they trust that you DO. If your CEO knows how (and when) to use '&' and you have
used wrongly it 40 times in a project proposal, they may ask what else are you bluffing knowledge
of. It sounds daft but perception is reality.
3 - Our documentation matters! Grammar experts say that '&' should not be used except for in the
most informal of communications. A project initiation document is among the most important
documents to the success of an IT Project. Anything that creates an impression that it is not should
be avoided. Susan the CIO asks, "Would you type a PID in the 'mistral' font or 'windings'? Would you
sketch it out in crayon? Of course not, it commands your best presentation skills - take some pride!"

4 - It's a trend! Why follow a trend, if you don’t understand it? I was in a meeting last week where a
forty-something-year-old project manager said, "Awse!" It was short for awesome. There was a
tangible sense of cringe about the room, even the PM himself looked uncomfortable. Apparently, it's
a trend! Doesn't make it right! To put this in perspective, these are fashion trends for 2019: 50s and
60s era couture gowns reworked shorter; volume dresses; corsages; ostrich feathers; front-loaded
tool belts slung across the body; and nineties style acid and light-wash denim. Do you understand
these trends? Will you be wearing them? So why follow the '&' overuse trend? (Although the light
wash denim sounds cool.)
5 - It may also dilute your message. My copywriter friend Gareth was on a course once where the
lecturer stated that in a list, a final item that follows the word ‘and’ is more likely to be digested by
the reader than one that follows ‘&’. It’s something to do with the reader being hardwired to take
pause when faced with ‘and’, whereas the attention zooms on and over the ‘&’.

6 - Finally, remember I said that out of ten IT Project Management professionals, only one nailed the
rules of the ampersand? Yeah, about that, Martina is from Slovakia. Come on people! We need to
pull our grammatical socks up!
This may be a tongue in cheek rant, or I may be the self-styled grammar police and mean every word
of it. I'll leave that for you to decide (by the way, my colleagues need not reply).
The point is though, that attention to detail has NEVER been more important. Your organisation
needs a decent return on investment, and you need to maintain high levels of successful project
outcomes to get the next green light. Therefore, we all need to get every aspect of IT Project
delivery right.

Knock, knock. who's there? The no joke approach to improving IT Project
performance



At a wedding recently, the nephew of the bride was a
bit of a comedian. He was about nine years old, with a
cheeky smile and we genuinely laughed when he
bounded up and delivered this joke!
"Knock, knock!"

"Who’s there?" we replied.
"Hatch"

"Hatch who?"

"Bless you!" he said drily, handing us a handkerchief.
Remember, the kid was about nine! Cute!



Some other guests walked into the marquee, so he moved onto this new audience.
"Knock, knock!"

"Who’s there?"

"Hatch"
"Hatch who?"

"Bless you!"

The elderly couple laughed. We smiled.
Then a third, a fourth and a fifth couple wandered in, they were all greeted by the same joke. All of
them laughed but the rest of us no longer found it funny. Around the tenth airing, someone who'd
arrived before us whispered that it was really starting to grate! Poor kid!
It got me thinking though.

The joke caused a genuine reaction the first time we heard it; less so the second; even less so the
third; and so on. You quickly become desensitised to something like a joke - it affects you less. So, if
we can do that automatically with something funny, why do we hold on to bad experiences?
Sometimes for years! Why do we let negative episodes in our careers affect how we approach the
here and now?
My colleague is working with an IT Project team who are struggling to innovate. Their issue isn't
scope creep, nightmares with budgets, problems transitioning into service or any of the usual
suspects - it is the baggage they are lugging around! The baggage of past project fails,
misjudgements and miscalculations are holding them back.

What's that old adage? Why do airlines have baggage limits? Because if they didn't their planes
would be too heavy to take off! So, it is with these guys. The past experiences of this team are
sandbagging their potential. Their past is influencing their decisions, creating a risk-averse
environment where innovation just couldn't happen! They can't take off.
There's a very primal instinct behind all this by the way! Often there is a part of us that doesn’t want
to let go of past trauma because erasing the memory completely might leave us vulnerable to the
same thing happening again. If it’s always on your mind then you’ll always be on your guard, on the
lookout for the potential for it to recur - then can run away from it before it even starts to cause
problems.

Congratulations if this sounds familiar - it means you’re human!!!! It's this instinct that kept our
ancestors safe from sabre-toothed tigers and we still have it today, long after the tigers have died
out.

Thing is if you are already biologically programmed to be affected less and less by that joke - is it
possible to reframe your thinking so that more negative events affect you less and less over time
too?

It turns out that you can! Furthermore, the results are amazing in our world of IT Project
Management.
Sometimes it can take a fresh pair of eyes to point out that you've become risk-averse or that there
may even be a Project Management as a Service solution to recurring challenges that eliminates any
risk altogether.
That team struggling to innovate had settled into a routine of not doing so through fear of failure
and as a result they were getting 'routine' outcomes. They weren't failing, per se, but neither were
they setting the world alight! They were letting past experiences influence their decision making.
Time and again they’d had to explain to stakeholders why their project had delivered, not with a
fanfare but with a whimper. It was becoming as funny that knock, knock joke!! Something had to
change.
With my colleague, they have explored the possibility that failure doesn't actually exist, i.e. it is only
failure if you don't learn from it; they have compared the 'worst that could happen' with the 'best
that could happen'; and they have looked at the team's three biggest failures and brainstormed
possible actions they’d take should they happen again. In each case, the potential benefit from
innovation outweighed the worst-case scenario and, anyway, resources from the PMaaS market
could have been called upon to rescue each situation. There you go, a lesson eventually learned
from each of the so-called previous failures!
There's a lot of talk these days about 'mindfulness', about living in the now rather than the past and
this may be the key here. The Project Management as a Service universe has exploded with new
solutions and resources since each of your past 'failures' happened. You cannot afford to approach
challenges with the mindset that you had the last time you faced something similar – the world has
moved on and so must our thinking.

These days, a return on investment is not an added bonus, it is a key expectation and that often
comes down to the quality of the project you deliver and how it transitions into service. Accessing
the most up to date project delivery tools is just not possible if your mindset is anchored in a time
when perhaps fewer options existed.

Maybe it’s time you stopped letting your past experiences influence your present? Maybe it’s time
to see how current solutions could help you to innovate? Maybe it’s time just to try something
different.
Like that kid at the wedding, project’s that don’t deliver their full potential are no laughing matter.
It’s time to stop being the butt of this joke.

Resistance is fatal. How to drive change in a change resistant environment



“To improve is to change; to be perfect is to change
often,” so said Winston Churchill.

He clearly never had to manage an IT Project in an
organisation resistant to change. I think we've all
experienced some of our darkest hours doing this.

I was chatting to a PM friend this week and he joked
that the organisational culture where he was currently
employed was so resistant to change that if all the staff
were on a train and it was announced that, for their
destination, they should change at the next station -
they'd stubbornly stay put and end up miles from where
they needed to be.

Some organisations are like this, aren't they? Time and again, Project Managers are told to go and
initiate strategic change only to find brick wall after brick wall.

The thing is, change is inevitable. In business, you either adapt and innovate or you die.
Most businesses are now dependent on IT, so it is increasingly the responsibility of IT to drive
business change and for many, this is a truth that hasn't been accepted. Amazingly, some businesses
still see IT as a back-office support function, they seem to be wondering, "What the heck are the
guys who come and turn PCs off and then back on again doing facilitating business change?" For
strategic change to have the most impact, organisational cultures have to have evolved in line with
this reality. Some have and some REALLY haven't!

Writing for ProjectManagement.com, Michael Wood says, "Most OCs [organisational cultures] grow
and evolve over time. Often, they are an extension of the founders’ own values and beliefs. Other
times, they are a collage of influences and practices that have just become the way things are." It
has never been more important for IT project teams to challenge this status quo, as Michael puts it,
"the way things are" to leverage the greatest benefit from a change programme.

1 - Know your own culture

I heartily recommend Michael Wood's article for many reasons, not least because he rather usefully
identifies a number of different business cultures from "Clan Culture" ("Friendly, family-like culture
where people share much in common") to "Hierarchy Culture" ("Formal and structured; processes
and protocols drive how people work and interact") and he suggests that different mindset is
needed in each case.
Michael highlights about four cultures, in my experience, every business has its own unique culture
and style and each different culture needs a different approach when it comes to managing change -
just as you'd interact differently with your children if one were a teenager and the other a toddler.

Approaching Michael Wood's "clan culture" model with a copious amount of data that proves the
need for a business change would be as ineffective as turning at the "hierarchy culture" with your
jacket slung over your shoulder and saying, with a winning smile, "C'mon guys - trust me on this."


You need to know your culture so that you know how to interact with it, when we provide Project
Management services it is one of the first things that we do - we get to know you. I can't imagine
operating in any other way.

As Michael Wood puts it, "When a PM meets with extreme resistance to change, they may be
experiencing a disconnect between their approach and the type of culture they are in. This is why
assessing the culture in terms of what drives its definition of “good” can help the PM avoid such
disconnects."

2 - Friends in high places

It has never been more important for clear and decisive leadership engagement throughout the
lifecycle of an IT change project. That is not to say that the project sponsor needs to oversee the
whole thing, but project managers do need a senior touch point in the event of an impasse. In my
experience, this can come in the form of an actual physical person who can be called upon to flex
some leadership muscle or as a clear document of intent that spells out the change and its
importance to the business.

Whatever form it takes, little shifts resistance to change like the fear of ending up on the radar of
your company's leaders. Business case is the most important thing for any IT Project, it is a PM's
responsibility to ensure that a project’s and its parent business' goals and objectives are aligned. The
greatest way to achieve this is to ensure that it is the business leadership - those that set the
operational culture - who communicate this or, at least, openly back it!
3 - Engineer "group get it" moments

When you have a group of people who perform similar roles or have a shared process at the heart of
their workday, it's amazing how quickly you can convince all of them of that a change is needed by
first convincing one of them. It's not that they're sheep but YOU are an outsider! Think about it -
who are you coming in telling them that there's a better way of doing what they do every day? I
mean - the cheek of it, disrupting their lives like this! However, when Sandra in sales order
processing gets it and becomes an ambassador for your change you'll find the rest will try harder to
understand. Ultimately, if you can convince users that the old status quo is no longer fit for purpose
and that the change is a new, better status quo then they are usually less resistant to change.
4 - Independence carries less baggage

Almost paradoxically, while you may be seen as an outsider, an actual outsider may find it easier
driving change in a change-resistant organisational culture.
While the finance guys may consider you an outsider, actually, you probably share the same water
cooler or canteen. In other words, you have to work with these people and, in my experience,
sometimes that is in the back of Project Manager's mind when considering a more confrontational
approach.
When you use talent and resources from the Project Management as a Service sector, i.e., when
change is being driven by someone who won't have to stand in line for a coffee, this is much less of

consideration. Resistant end users are more likely to throw a spanner in the works when they feel
comfortable doing so, in other words when they know the person driving the change - familiarity
breeds contempt.
There is a lot to be said for a fresh pair of eyes!

5 - Clarity of purpose is King

It sounds obvious and, of course, you would never start an IT Project without being clear on the
intended outcome ... right?
That clarity has to be taken to another level when dealing with a change-resistant culture. The
slightest chink in the stated goals of a project can wreak havoc. If there is the smallest doubt - the
change-resistant will jump on it - and doubt spreads fast. To leverage maximum project success
objectives are not flexible, goals and non-negotiable and this has to be clearly and authoritatively
stated at the start and throughout by the organisation's leadership.

If you’re driving change in a change-resistant environment, I hope that this helps, and I would love to
hear any ideas you have.

Philosopher Friedrich Nietzsche once said, “The snake which cannot cast its skin has to die."

Inability to facilitate strategic business change inevitably has the same impact on your organisation.
In IT-dependent organisations, (i.e. most) it is the responsibility of the IT leadership to make change
happen, for many this is a new skillset, for many more it is a natural extension of existing ones -
whichever category you fall into getting better at driving change against resistance or having a
contingency plan with a project services partner is well worth it.

Resistance is fatal.




Source:

https://www.projectmanagement.com/articles/472533/Managing-Projects-in-a-Change-
Resistant-Culture-

Resolutions Are So Last Year! How IT Project Leaders Are Pledging Success in

2019


(At the time of writing)
Back to work, eh?

So, how are your New Year’s Resolutions working out?
Personal and professional?

Probably, if you're like most people I talk with, you’re
having a mixed bag of results.
Now that's sort of OK with the personal stuff. If your
resolution was to eat more healthily and hit the gym
but you're still popping buttons off your shirt when you
breathe out, well, you have time to make changes to
your lifestyle.

If, on the other hand, your New Year Resolutions were professional it may be that failure to stick to
them could cost you some IT Project wins.

I read that 80% of New Year’s resolutions fail by the February. The reason? Usually, no commitment.
Resolutions tend to be things that you THINK you should be doing, so quit smoking, take up running,
meditate daily in your personal life or eliminate scope creep, set better KPIs, explore more efficient
Project management as a Service (PMaaS) options in your work life. The thing is that these are all
great goals but then along comes that nicotine craving on a stressful day or a key stakeholder with
"just a small request" and often you cave in ... the path of least resistance is littered with broken
resolutions!

If your resolutions are lacking a strong foundation of personal meaning and relevance the chances
are that they won't deliver the difference that you intended. What you need is something much
more fundamental and important to you because when your resolve comes from the inside, based
on something that matters to you or genuine past pain, you have a much greater chance of seeing it
through.

With this in mind, this year instead of New Year Resolutions, a few of my IT Project friends have
made New Year Pledges. They're more specific and measurable than resolutions and because they
are based on actual pain points it will be interesting to see how effective they are. Here are some of
them.
1 - Clarity on responsibilities

Martha's team are big on delegation but 2018 threw up issues around clarity on who is responsible
for what. "Three or four times there were instances where something would need attention and
when we looked for the right person to sort it - no-one knew who that was!!!" Increasingly, Martha's
projects span different offices, even different continents and this is making it even more important
to nail down who is doing what! It sounds really basic, but she is not alone.
Specifying which team member is responsible for what task and making them accountable for it is a
key pillar of project success. Martha has invested in a real-time task management system that can be

accessed online and it should do the trick but there are many options available from the PMaaS
universe that can also help organisations stay on top of task and resource management.

2 - Full project details - Up front!!

Ensuring that you have full project details before you start may seem like an obvious call but,
according to Martina, a project scope, fully approved by all stakeholders, isn't always the foundation
upon which IT projects at her organisation are built.

The more detail your initial project brief and documentation have, the more chance you have of
succeeding. You wouldn't build a house without first getting an architect to draw up the plans!

Martina's pledge for 2019 is to refuse to start a project until milestones, budgets, deliverables and
delivery dates have been signed off and agreed by key stakeholders.
3 - Stay focussed on the Why

Martin's pledge for 2019 is also based around scope creep.

"2018 was the year of missions getting side-tracked by requests from stakeholders that could and
should have been totally separate projects with separate budgets and timelines to go with them," he
told me. "It's been like we're baking a Victoria sponge cake and the stakeholders have come into the
kitchen and said, 'You know what would be nice too? Shepherd's pie!' We need to be better at
saying - that would be nice but right now we're baking a cake."

Martin's pledge is to remain focused on the why. The reasons you initiated the project and the
business case for it. "We'll accommodate change requests when they support the why. If you want a
sprinkle of icing sugar on top of the cake - you got it! If you want minced lamb, gravy and mashed
potatoes then that's a new project so, don't be offended if we ask for a new budget."

4 - Motivated milestones
Kyle has pledged to keep project team members motivated by rewarding them when individual
milestones are reached. "I noticed that we're really good at cracking open a bottle of bubbly when a
project is delivered into service but successfully completing chunks of work, the cornerstones of a
successful project, tends to pass uncelebrated."

"Teams can decide what reward they'd like, within reason, chocolate has been the runaway
favourite so far, but one team has a night of ten-pin bowling riding on the successful completion of
their current task. We've put a bell in the office and that gets rung by the team when they win their
reward. We trialled the initiative since about September and it is helping keep track of individual
work parts as well as inspiring better performance!"
5 - Be break aware

All of the booze bottles I opened over Christmas had the words "Be Drink Aware" on them. This,
apparently, has inspired Hannah to be "Break Aware".

"It was a dark, late November afternoon when I realised that I'd not moved from my desk and taken
my eyes off my screen for more than three hours," says Hannah. "It dawned on me that for probably
half that time I'd been operating on autopilot and not giving my work my best attention. I looked
around my team and we all looked exhausted!"

Does this sound familiar? I mean I've been writing this blog since just after breakfast on and its now
nearly lunchtime - I haven't shifted from my seat, my eyes are tired and spell check keeps
underlining my mistakes with a red wobbly line. Now, this is just a blog and doesn't matter in
comparison to an IT Project that I may be working on when I return to the office. Then my
performance WILL matter and could be the difference between success and failure.

Hannah's pledge is that she and her team will work in 30-minute bursts and after each one, a short
refresh break will be taken. On that dark November day Hannah took a walk out onto the street
outside and felt the rain on her face, I've just taken a stroll around the car park and inhaled some
fresh(ish) air!! A short break re-energises you! And yet many of us don't take them!

It's no wonder IT Project work can be so stressful at times, we're running on pure caffeine. Take a
break. Take a deep breath. Your project will thank you for it.

So, there you have it, pledges may be better than resolutions. Time will tell. Let me know if you’re
pledging to make some measurable changes in 2019 – I would love to hear about them and help you
achieve them in whatever way I can.

The 7 Killer Traits of a ROCKSTAR Project Manager - A CIO's Checklist




A CIO sprang this on me this week. "David, what makes
a great Project Manager?"

It's one of those questions that you answer instinctively
- great organiser, they deliver projects within deadline
and budget, good communication skills, etc, etc. All true
but I was a little disappointed by my instinctive, off the
hip answer - I mean these are all pretty basic role
requirements … PM's who can't communicate or
organise don't last long!

The thing is, I have had the pleasure of working with
some Rockstar Project Managers! So, I gave this
question some more thought on the drive home and
then emailed a more satisfactory response to the CIO
who posed it and I thought I'd share it with you too!

I'd love to hear from you … do you agree or disagree? Is there something that I have missed from…

THE SEVEN KILLER TRAITS OF A ROCKSTAR PROJECT MANAGER


1 - They have an entrepreneurial streak

More and more I am seeing Project Managers with a real entrepreneurial streak who are running
projects like micro businesses within their parent organisation. There are of course huge advantages
to this trait, not least that projects tend to come in within budget when run they are subject to a
business-like level of scrutiny. Beyond this, though great entrepreneurial Project Managers are
spotting extra revenue opportunities both within their current projects and in the wider business.

In the same way that Sir Richard Branson surrounded himself with brilliant people, entrepreneurial
Project Managers build great teams of complementary talents within your company. Entrepreneurial
Project Managers are instinctively driven to build and manage great teams and also to deliver
innovative products.

2 - They are fabulous people managers
Actually, I think that this a trait that sets Project Managers and Project Leaders apart. Great
managers manage things, great leaders lead people.

Watching Gareth Southgate at the 2018 World Cup perfectly demonstrated the latter, the way he
connected with his team as individuals and seemed to know what made them tick should be an
inspiration to anyone tasked with building a team.

One of my PM friends who falls neatly into this category has an intense dislike of the term 'human
resources' and actually successfully campaigned for his firm's position of HR Director to be
rebranded Director Of People.

3 - They roll up their sleeves/have experience beyond Project Management

A CIO once told me about his favourite Project Manager. This guy didn't merely manage the project
he did his best to live and breathe it by rolling up his sleeves and spending time in the places where
the project would have an impact. He observed the processes and working practices, he got to know
the typical characteristics of the end users and asked their opinions. Once, he even spent a morning
working manually on the factory floor to get a true end to end sense of the effect that a project he
was managing would have. This is exceptional and you may not have time to do this but gaining
experience beyond Project Management duties gives a manager valuable new perspectives and
insights.

4 - They are the King/Queen of collaboration
Collaboration may be the single greatest weapon in an effective project manager's arsenal.

Firstly, there's collaboration within the team. A great project team leader inspires a sense of
togetherness and has the ability to identify points of contention, intervene, find a solution and keep
the project running in its intended direction of travel.

Secondly, there are the extended collaborative benefits that an independent project management
services partner can bring. Great leaders know when they need talent and resources to complement
their in-house team and they know where and how to find them. The Project Management as a
Services market has infinite collaborative opportunities and the greatest PMs either know how to
choose what's right or they collaborate with a services provider who will.
5 - They know how to eat a Whale!

"How do you eat a whale? One bite at a time". I love this saying. There was a poem by Shel
Silverstein that I read in one of my children's books years ago that went "Have you heard of tiny
Melinda Mae, who ate a monstrous whale? She thought she could, She said she would, So she
started in right at the tail," and it goes on, "She took little bites and she chewed very slow." IT
Projects are like this - huge monstrous projects can only be achieved by breaking them down into
bite-sized, easy to manage pieces. The best PMs can instinctively reduce complex projects into
achievable work units.

6 - They are great 360 degree communicators

Communication skills is a given, but a major difference between good and great project managers is
their ability to communicate with colleagues at all levels. Effective project leadership needs clear
communication.

You have to communicate with your team about their responsibilities, the project's goals,
performance expectations, and of course you must be able to give meaningful feedback that can be
acted upon.

Beyond this, of course, you also have to communicate UP! The finest Project Managers are great
negotiators. They tell stakeholders and project sponsors what they need to hear as opposed to what
they think they want to hear - the difference between these can be the difference between success
and failure. They are not afraid of rank and have the same confidence communicating with an end
user of their delivered project as the organisation's CEO.
7 - They are problem solving, decision making MACHINES!!!

The average IT Project throws out problems to be faced and decisions to be made by the bucket
load. Have you noticed how some PMs instinctively know what to do … and they just do it?

The quality of decisions can define the progress of your project, one false move and you can be in
real trouble - how often has a single decision, seemingly minor and irrelevant in nature, put an entire
project in jeopardy?

So, there you go. The 7 Killer Traits of a ROCKSTAR Project Manager - A CIO's Checklist. Have I
missed anything obvious? Do get in touch with any thoughts and if you need Rockstar project
management (as a Service) for your IT projects … I'd love to help you with that too.



I really enjoyed thinking about what makes a great PM - meditating deeply on the question made me
feel grateful for the wonderful talent that I get to work with and hugely appreciative of the work I do
… and maybe that is the bonus eighth trait of a rock star Project Manager - whatever the ups and
downs, whatever the challenges … they LOVE IT!!

The Roast of a Project Manager




Have you seen the TV show "The Roast Of …"?

Basically, it's like 'This Is Your Life' (if you remember
that back in the day) but instead of celebrities coming
on and praising the subject of the show, they turn up
and spill the beans on their bad habits and worst
moments. The most recent one I saw featured Bruce
Willis and Demi Moore was hilarious roasting her ex-
husband.

I wondered what kind of stories would come up if they
did an episode entitled "The Roast of A Project
Manager" and so asked a bunch of friends and
colleagues in the industry. Their replies made me smile and actually read like a handy list of mistakes
to avoid when managing an IT Project!

Get in touch and tell me the stories that would make you cringe if you appeared on "The Roast of
You" and in the meantime … enjoy …

The Roast of a Project Manager

1 - Big project / little experience

A couple of PMs messaged me back to say that they had once bitten off way more than they could
chew - the result - they choked!

Matt emailed to say, "It was my third IT Project, the first two had been runaway successes and I
thought I could take on the world! I was wrong! I took on a project that was way too complex for my
experience level and it very quickly started to teach me lessons. The greatest lesson that I have kept
with me throughout my career is to be humble and if I think that something is beyond me or my
team - ask for help! Over time my experience and confidence have grown but I am still mindful of
not stretching my team's resources in a pointless show of bravado! The Project Management as a
Service sector is like a magic genie of resources!"

I wonder how many other PMs would expect this to crop up on their "Roast Of …"? Matt's lesson
from those early days of his career is one that we can all take note of. In my experience, project
sponsors, stakeholders and CIOs are much more receptive to honesty upfront about a capability gap
than they are to the news that your inexperience has caused the project to fail.

2 - Lack of business case clarity

Julia messaged me to recall the IT Project that she once initiated with only a basic understanding of
the parent organisation's needs. "It didn't end well," she remembers.

"To be fair I was pretty new at this firm and less confident about confrontation than I am now. The
brief was so full of holes it could have been used as a colander! These days I'd push the brief back,
ask questions, insist on a proper document that detailed requirements. Back then I just thought, OK,
I have some information, I'll have to fill the gaps for the rest!"

Filling gaps in a project's business case needs is an easy trap to fall into. The best you can hope for is
that you nail it but even in this case how much credit do you think you get? You can't say, "Hey look
at this project I delivered despite the lousy brief." That never goes down well! Worst case scenario is
that you get it wrong and the project fails to deliver on its business needs - suddenly the credit for
this is all yours!

No, Julia is right, if the brief doesn't spell out what the project should deliver for the business keep
sending it back until it does!

3 - Inadequate initiation

Malc wrote to me to say that he shudders at the memory of an IT Project which started without a
proper starting plan in place. "I mean," he writes, "Everyone knew what they were doing. It wasn't
the most complex IT Project ever. We all agreed to crack on."

"Cracks started to appear when two team members got their wires crossed about their
responsibilities. Soon roles got blurred, project milestones weren't defined and so got missed and
finally, the delivery deadline date had to be pushed back due to the rather slapstick way that we
were operating."

A project initiation meeting is vital so that everyone sets off in the same direction at the same time!
What's that old saying? Proper planning prevents poor performance .. so true of IT Projects! I
honestly think that it could be the most valuable time that you spend on your IT project, a chance to
double check that everyone is sure about their role and what the project is meant to deliver.

4 - Scope on a rope - a Bungee rope!

At some time, who hasn't had scope creep rob them of project glory?

Lydia emailed to tell me about the project that taught her the value of saying 'no'.

"We started off with a tightly agreed project scope, everyone seemed fully bought in and engaged
and REALLY friendly. Then a lot of afterthoughts started to surface, a lot of requests for things that
would 'be kind of nice' to incorporate and each of them had a sound business justification. There
was no procedure for assessing scope change requests and as each was fairly inconsequential in
terms of budget and delivery date, we waved them through. The problem was that although they
were inconsequential in isolation they added up and we blew the budget!"

At this point, it's amazing how all the people who emailed their ideas for bonus project extras seem
to disappear leaving you, as Project Manager, to carry the can.

Lydia says, "Once bitten! Every project I ever worked on since has had a procedure for scope change
requests and assess them based on their business case, impact on budget and how they'll affect
delivery."

It was interesting that most of the replies I got referred to mistakes that happened in the dim and
distant past. Experience teaches great lessons and I think that, in IT Project Management, we are
constantly learning.

I am!

One of my major passions, the Project Management as a Service sector, is a constant teacher and is
expanding to levels where there is a solution for just about every issue that could potentially lead to
a project failing. It is certainly worth exploring if you have a challenge. Then, if they do ever make
‘The Roast of a Project Manager’, at least it won’t be about you.

Straight Talk On Project Management


Chapter Two – Leadership





WISE WORDS

"One of the true tests of leadership is the ability to recognize a problem before it becomes
an emergency." ~ Arnold Glasow

"The key to successful leadership today is influence not authority." ~ Kenneth
Blanchard

"Inventories can be managed but people must be lead." ~ Ross Perot
"Management must manage!" ~ Harold Geneen

"Vision without action is a dream. Action without vision is simply passing the time.
Action with Vision is making a positive difference." ~ Joel Barker

How close to achieving this year’s IT Project goals are You? Time to “aaSk”
for help?



As I write this, we are now well into the final quarter of
2018. October will soon become a distant memory,
November will fly by in a blaze of bright lights as
calendars are punctuated with celebrations for Bonfire
Night, Diwali and Thanksgiving and then we will be on
the inevitable treadmill to Christmas and the end of the
year.
So, with that in mind, if you set targets for 2018 at the
start of this year ... how are they measuring up? Are
your IT Projects hitting the milestones that you hoped
they would by this point? Or have they gone the same
way as those New Year resolutions?!

Completely unscientific this, but a quick call around
some project management friends reveals that most have projects that are lagging somewhat
behind their ambitions.

Now, my specialist chosen subject, were I to go on Mastermind, would probably be the Project
Management as a Service market. I find it fascinating how this sector has evolved to meet just about
ANY IT project challenge and more and more innovative solutions are added to the 'brochure' every
day. These friends with projects that are struggling know this, so I asked why they hadn't called to
see if there was 'something out there' that could help.

The biggest reason was, cost. There was a perception that PMaaS would cost too much. You know
what? Project management as a Service can actually even help you reduce costs or in many cases
lead to no net cost increase. It's one of my favourite myths to debunk. Even in worst case scenarios,
the cost of using PMaaS resources is usually insignificant compared with, say, the cost of a failed
project.
The other most popular answer was really interesting. They almost all said something along the lines
of this ... "to ask for help would be an admission of failure or it would look bad on their own
capabilities".
I asked who would judge them in this way. The most common reply was 'my boss', followed 'my
team' or 'stakeholders', one friend even thought that the PMaaS partner they called might judge
them in the way that a mechanic might if you took a badly maintained car in for a service.

This needs a reframe.
Firstly, I have never met a boss or stakeholder who judges anything other than end outcomes. OK if
you turn up on delivery day with an incomplete IT project or one that is WAY over budget - you're
gonna get judged. If, on the other hand, you parachute in PMaaS resources to deliver on time or on
budget, you will be judged on that success and not by the means with which you achieved it. In most
cases this is true.

Secondly, your team will not consider you a failure for reaching out, nor will they think that PMaaS
resources are a reflection on their performance - unless you tell them that this is the case. They are
more likely to be grateful that you have seen how hard they are working or that you have
appreciated that the complexity of your project is perhaps beyond their current experience and
capabilities. They will be glad of the assistance to get them over the finish line.

And thirdly, no-one from the PMaaS market will judge you. They are in business for just this kind of
thing and they will be glad of the opportunity to serve. They want the business!! If they ridiculed or
judged you, because of the state that your project is in then they probably wouldn't get asked back
again and certainly wouldn't get the precious recommendation or referral from you that could lead
to more work in the future.
Asking for help is a strength, not a weakness.

Seeking assistance with your IT Project is no different to being lost in a city that you don't know. If
you are in a strange town to watch a gig or cheer on your team at a football match and you can't find
the theatre or stadium - do you just keep walking down street after street in the hope that you get
lucky? No. You ask for directions.

And what does the person you ask do? Do they laugh at you? Judge you? Do they tell you that
they're too busy? Do they tell to buy a map or open the one on your phone? No, they just give you
the directions. I love helping lost tourists get to where they want to be, I have even opened the map
on MY phone to show someone the way before now.

Human beings are mostly wired this way and the proof comes in what happens after you give
directions. You spend a good five minutes gesturing with your arms, pointing left and right, basically
sharing your hard earned knowledge, even recapping (without being asked) in case they missed any
of it ... and then what? The person says thanks and off they go. You don't get a box of chocolates or
bottle of wine for your troubles, they don't take your name and address so that they can send you a
Christmas card, they don't rifle through their pockets for loose change - they just go. What a user!!
BUT, if a hundred yards down the road someone else said, "Excuse me, can you tell me how to get to
the station?" - you'd stop and help them too.

You don't judge a lost tourist for being lost and no-one in the PMaaS sector will judge you for asking
for directions with your IT Project either. Actually, they'll be happy for the chance to show off their
knowledge!! AND the best thing is that, by hiring in PMaaS talent, you get to be a knowledge
sponge!! In the same way that the lost tourist will now always know how to get to the station, you
and your team will acquire new skills that you can take forward in your careers.

On-demand project management resources, which is basically what PMaaS is, allows you to flex your
processes to your specific needs of your project portfolio at any given time. Sometimes you’ll need a
lot of project management support perhaps to get past a difficult challenge and other times you can
get away with less.
At Stoneseed, our PMaaS offer is a team of Project Management, Technical and Service Delivery
Professionals, delivering services through a flexible, on-demand resourcing model. From strategy to
service delivery, this cost-effective model for project delivery is underpinned by Stoneseed’s PMO,
methodology and toolset. What that means is that whatever is holding your project ambitions back,
we have the solution. Wherever you have got lost - we can give you directions! We love a new
challenge, believe me, whatever mess you're in we are so ready to help you unpick it.

I find this time of year is a great time to assess IT Project performance against milestones and take
corrective action if needed. Apart from anything else, we are about to head into 'peak sickness'
season and knowing what your capabilities are and how much of your in-house resource you could
afford to lose to a flu bug without impacting your projects is a great piece of insight to have. Having
a PMaaS partner on speed dial as a backup plan is just sensible precaution.

Knowing that your IT Projects are on track and underwritten can allow you to fully enjoy whatever
holiday season you are about to celebrate, safe in the knowledge that any fireworks that do go off -
won't be in your project portfolio!

How to prevent holiday hold ups delaying your IT project!




Who is your IT Project's Leader?

At this time of year (holiday season) are you really
leading or is your company's calendar more in charge?
I ask because, independently, three Project Managers
have told me that they are pulling their hair out
because of unanticipated roadblocks along their
projects' critical paths. In each case, the cause is the
absence of key decision makers ... who are (or are
about to go) on holiday.
The worst I've heard is my friend Steve who sent
invitations out for a meeting the following week for
some go/no-go decisions that were about to need
addressing. Of the five invited attendees, two replied they could be there, two would be away on
their holidays and the last to reply, Mike - the key decision maker (and not his real name) - hadn't
replied by the close of play. Steve chased his request up with an email and eventually got a reply
that the diary the following week simply had no room to accommodate the meeting. Mike was also
heading for the sun, for three weeks and although he was in the next week, his diary was crammed
with clearing down jobs in preparation for his break.

Imagine this, as a Project Manager, four weeks is a long time to have to wait for answers. The go/no-
go decisions that were gently approaching the point where a meeting would be needed would
become critical issues in that time. Steve picked up the phone and had what he called "a friendly
rant" and within minutes the pair were sorting through the matters.
At this time of year, we see scenarios like this repeated at various businesses to whom we provide
Project Management support services and I have often been asked what the solution is. I don't have
the silver bullet, but I do have some thoughts.
1 - PMaaS

Naturally, there are solutions available from the Project Management as a Service sector. The closer
your relationship with your partner the better, i.e., the more your services partner understands you,
your culture, your portfolio and your priorities, the better they can identify potential issues and key
decisions that will need to be taken.

2 - Just do it

I'm not sure who it was that first said that it's easier to ask for forgiveness than permission but in
cases like these they were right. The thing is if you are living and breathing an IT project the chances
that you'll make a decision that is harmful to it are very small. Think about it, in the instance above,
Steve had a number of suggestions for each of the issues the project would be facing, some would
be better workarounds than others but each of them was a "good move" to make. On balance, if the

clock is ticking on your project's critical timeline, doing nothing is usually more harmful than doing
something - even if that something is your second or third best option.

3 - Change your culture to recognise priorities and allow time for dealing with them

Mike, the stakeholder with the power to make key decisions in the short case study above sounds
very old school to me. In your career, you'll have met people whose measure of effectiveness is a
full diary. It's a mistake though to let "busyness" get in the way of business. Steve's project had a
well-defined business case and strategically it was key to business goals, but Mike was willing to
sacrifice these because his diary was full of the workplace equivalent of making sure someone
waters the plants and feeds the cat!

4 - Clarity in delegation
Often, holiday roadblocks can be avoided with clear, well defined, unambiguous and proper
delegation - i.e. if you trust someone to do something let them crack on. Of course, if the talent
running your IT Projects doesn't have your trust to make the right decisions then you could graft in
more experience from the PMaaS market or set up better systems internally to allow decisions to
happen more automatically. One Project Manager we work with takes the proactive approach of
emailing key decision makers with a three-step approach. First, he spells out clearly what the
challenge is and its potential consequences, second, he gives it a time frame (i.e. when does action
need to be taken) and finally he offers his opinion on the best solution. It takes a key decision maker
thirty seconds to read, agree and give the green light or a little longer if they have input of their own.
Usually, it is a straight instruction to proceed.

5 - Key decision makers can actively check the road ahead for blocks

In most cases, issues that are accentuated by holiday absence could have been spotted previously
and early, well considered and decisive action could have been taken. Take Steve and Mike, to be
frank, one of them could have taken a helicopter view of their project weeks ago and flagged up all
the challenges that they would be facing down the line. Whose job this is will differ depending on
your delegation structure and maturity ... BUT how much better for all concerned to have issues
nailed early!

6 - Prioritise priorities

This sounds obvious and we sort of touched upon it in point 3 but it deserves a second pass. It strikes
me that we live in an age of the fastest ever communication with the slowest ever response times.
You can ping a question into someone’s inbox in a second flat but often the response feels like it’s
come by second class post. The problem is all the other noise that your email is competing with. As
the sender, you have to get REALLY good at using language that really grabs the attention of the
recipient and they, in turn, have to get REALLY good at filtering out all the clutter and dealing with
the important and urgent.
I was chatting recently with a retiring CEO and he was reminiscing about the time before email and
what he calls "self-service diaries". He said he had a personal assistant to run his diary, the post
would be opened, filtered, allocated and prioritised by this same person and only things that needed
his attention were passed to his in-tray and anyone with more urgent issues would pick up the
phone and during that conversation they would get sorted. He then compared this to the reality of
communication in the [email protected] era. Anyone can access anyone
about anything, this chap's personal assistant wasn't replaced when she retired as he was expected

to set an example by running his own diary, etc. He had to make many more judgement calls on
what mattered. We all do and, sometimes, we get it wrong.

7 - "Use the Force, Luke!"

I love that scene in Star Wars were Luke Skywalker is piloting his X-Wing to destroy the Death Star
and he turns off his navigation computer upon hearing this instruction from 'force ghost' Obi-Wan.

As Project Managers, sometimes we over-rely on our fancy project management software and IT
solutions - of course, we do - we're in the IT solutions business! However, as a PM friend, Malc once
observed: "my butcher isn't vegetarian, but he sometimes eats carrots." What he meant was that,
sure, we're in the IT Solutions game but sometimes the best route for the project is more low tech.
In the case of Steve above, I can hear "force ghost" Obi-Wan screaming "Use the phone, Steve!"
Point seven then is, trust your instincts and act upon them to get the answers that you need.

In conclusion, holidays have enough delays of their own, whether its striking French air traffic
controllers, miles of cones on the M5 or just lots of people waving their Euros ahead of you at the
bar, the last thing you need is to come back to find delays with your IT Projects. Have a great holiday.

IT Project Leaders must be quick off the blocks, on your marks ...


Oh my!!

Have you seen the video of 7-year-old runner Rudolph
'Blaze' Ingram who sprinted 100 metres in just 13.48
seconds?

It's fascinating to watch this young Florida athlete speed
out of the blocks; and after clocking up thousands and
thousands of Instagram views, as I write this, he has
made the national television news here in the UK. To
put this all in context, 9.58 seconds is the men's world
record, set by Usain Bolt in 2009, and the women's
record, set by Florence Griffith-Joyner in 1998 is 10.49
seconds.

Wow!! Those of you who know me will testify that I too, cut rather an athletic figure and for us IT
Project Managers the similarities don't end there.
Reading more about this remarkable young man and listening to former athletes analyse the video it
struck me how carefully planned every metre, almost every centimetre, of a 100-metre sprint is at
the elite level.
When launching an IT Project, leaders and managers and their teams need to be equally quick out
off the blocks and we too have to be meticulous and disciplined in our planning and execution.
The start-up phase of an IT Project is like a 100m sprint, over quicker than you think and what you
get out of it at the finish tape is entirely dependent on what you do every step of the way. The 100m
sprint is a pretty good metaphor for the first 100 days of an IT Project, especially for a new project
leader within an organisation.
Let's run through it together.

So, the starter's pistol fires and you are off ...

0-25 Metres - Assess!
This is where you prepare and suss out your surroundings. By the 25th day, you should have
completed your preparation and assessment phase. You should be engaged with key stakeholders,
staff and organisational leaders. You should have learned what requirements and pain points need
to be addressed first. Perception is reality and these early stages really can establish how you are
perceived within the wider organisation - this will pay you back later if you get it right! When you
establish strong relationships across the organisation, with influential executives who understand
the value of the PMO, when you establish good reporting structures with these individuals, you will
find that when you need support further down the track - it will be much more forthcoming.

By this stage, you should have assessed your resources and established what gaps you have and how
you are going to fill them. Do you have the staff in-house to deliver the project, or will you parachute
in resources from the Project Management as a Service sector?

I also like to identify a few key challenges that can be tackled and put to bed during the 100m sprint.
Your capability to deliver visible results early on can create a powerful perception within your
organisation that often means you get the benefit of any stakeholder doubt later in the project...
20-50 Metres - Plan!

Around 20 days in, and still during this assessment phase your thinking needs to be split between
the assessment phase and the start of your planning stage. The planning part of the project can last
until about your 50th day - the halfway stage of your initial sprint!

Plans should be flexible and clear, simple but well defined, ideally, you are also be preparing an
action plan for your second 100-metre sprint at this stage too.

Canvass the opinion of key stakeholders around this time also, share your draft plans with them and
based on their reaction and enthusiasm make appropriate alterations.

At this stage, really think about the resources that you'll need to execute your plan. Recruiting from
within and explore Project Management as a Service resources you may require to help deliver your
project.

40-90 Metres - Action

Again, this stage overlaps the last and I cannot stress the importance of starting to act as soon as
possible - if you feel confident to start executing sooner than this, don't hesitate! The greatest PMOs
start implementing plans that they can alongside their long-term planning phase. I reckon it's not
unreasonable to expect to complete one or two major milestones during this time - be bold!
Shout about ANY successful early result, your credibility increases with every early win, so don't be
afraid to blow your trumpet! These results broker engagement across IT and business management
stakeholders.
40-100 Metres - Measure

Measurement of the results of your actions should actually begin at the same time you start taking
the actions themselves. The more you measure, the more you anticipate and the more you
anticipate the more you succeed.

The final third of your initial 100m sprint should be focussed on creating firm foundations for the
future and a launch pad for the next phase for your maturing PMO. This current project will fit within
your wider project portfolio management (PPM) ambitions - now is a good time to measure that
too!

The confidence and credibility gained throughout this first stage really pushes you on, not just in the
physical sense either.

In one social media post, the star of our story, young Rudolph is pictured with a serious look on his
face as he gets sets for a race and the caption reads 'My Father Told Me That You Win Mentally
Before You Win Physically, I'm #1 Before The Race Starts.'

I've seen projects succeed and fail based on the quality of mental preparation - teams that visualise
success usually succeed and teams who visualise lots of problems encounter lots of problems. It's
easier to achieve success that you've planned for and the earlier that success comes (remember
those early milestones) the sooner they can have an impact on morale.

Of course, at this stage, the work of the 100m sprinter is done. For you, the finish tape of this initial
sprint is just the beginning, but it will probably feel like less than 14 seconds have passed. Time flies!



Now, get your breath and run on!

IT Project talent shortage. Is PMaaS plugging the gap?




A quarter of digital leaders (25%) believe that their
business has an IT Project Management talent shortage.
In many ways this is good news, I mean, this suggests
that three quarters don't have a shortage, right?!

Actually, it's even better news than that! The same
report back in 2015 suggested 34% of CIOs had an IT
Project Management talent gap, a healthy nine-point
move in the right direction is music to my ears!
Increasingly though, IT Projects are linked to business
strategy so the fact that 25% of CIOs report a shortage
should still send a ripple of concern across the industry.
The figures come from the HARVEY NASH / KPMG CIO SURVEY 2018 and, as always, the survey of
almost 4,000 digital leaders across 84 countries makes for interesting reading.

Across IT as a whole, 65% of leaders report a lack of talent is holding their organisation back.
Significantly, almost half (46%) now use outsourcing to access skills. Certainly, over the last four
years, we have seen an increase in demand for and supply of Project Management as a Service
(PMaaS) talent and resources.

A vibrant services market could explain why the skills shortage, in Project Management at least, is
trending down whereas across the wider industry over two-thirds report strategic delays caused by a
lack of talent.

To test this theory, I decided to look at some talent shortage areas as expressed to me by IT Project
leaders and consider how the PMaaS market was used to fill such gaps.

1 - Initiators - Not just facilitators
Many project managers are still super focussed on resource management and while it is important
that people and resources are where they're meant to be, most strategic IT change projects demand
greater emphasis on Project Managers to be in the thick of the decision-making process. For many
projects, it is no longer enough for the PM to turn up and execute a plan, they have to understand
the business case, the risks and how the goals of the business and those of the IT Project are linked.
Rather than just facilitate projects they are actively a part of the decision-making process based on a
firm understanding of the needs of the business.
End to end project management services have certainly helped fill shortages here. When there is
clarity of purpose, the right talent can be drafted in to efficiently execute change projects from
initiation to delivery - BUT you have to make sure that your services partner gets to know your
culture and your business needs.

2 - End goal focussed PMs who are great communicators

Many businesses are looking for greater transparency throughout the life cycle of a project - it is
essential for more complex projects. I've seen a few examples recently where Project Managers
have been super-efficient at breaking down project tasks into manageable chunks but haven't also
had an eye on the overall health of their project. Change initiatives, which many IT Projects are now,
attract cynicism from change-resistant stakeholders and if you give the slightest sign that a project
has veered off its long-term course - or you don't give feedback at all you can quickly lose their
confidence.
The ability to take a 'helicopter snapshot' of both the immediate and long-term health of a project is
a strong trait of many working in the PMaaS sector. I suppose it comes from the nature of the work,
when you are parachuted into a new environment you have to be able to make quick and accurate
judgements and communicate your understanding and action plan.

3 - PMs who spot issues and who have the bravery to hit the stop button

I've seen this scenario play out a couple of times where something is wrong with an IT Project but
no-one flags it up. Either someone else will, or team members don't feel empowered to do it - I
actually heard a project manager say that pressing the brake pedal was "above his pay grade". When
an IT Project shows the first sign of a problem EVERYONE has the responsibility to bring it to a senior
manager's attention - at least.

There is still WAY too much politeness and thinking that flagging up an issue makes you a trouble
closer.

Funny how talent hired through a PMaaS arrangement don't have these hang-ups, it's not that they
don't care about hurting feelings or treading on toes it's just that they weren't hired to sugar coat
issues - they were hired to deliver the project. If there's an obstacle standing the way they make sure
that they get the attention of whoever can remove it!
4 - PMs with big tool kits

How organisations run projects has changed. Now that digital is at the core of most businesses, IT
Projects are almost always business change projects. This usually requires a great deal of flexibility in
approach - one size no longer fits all.

Agile often allows teams to keep pace with organisational demand and has been deployed as the go-
to, default methodology for many. To have it as the only trick up your sleeve though is short-sighted
in the extreme. Project Managers who have a range of skills in their locker are increasingly in
demand but often are thin on the ground.

PMaaS provides this in spades! In the same way that travel broadens the mind, exposure to many
methodologies and approaches organically grows a Project Manager's response options.

5 - Stakeholder savvy PMs

A CIO I know doesn't measure success just on how near project delivery is to the promised date or
how close it is to the forecast budget. She believes stakeholder satisfaction is more valuable than
these traditional metrics - so a project that delivers late and is a tad over budget but which delivers
business benefits for all stakeholders (end users, customers, etc) is considered more successful than
one that comes home on time and on budget but has a neutral effect on the business.
She particularly prioritises customers - the rest of the business is very focused on customer
requirements so why shouldn't IT Project Management?

"Our competitive edge comes from our ability to identify an opportunity and quickly deliver IT
Projects that monetise it," she says, "finding Project Managers who have the ability to spot such
opportunities and quickly act can be tricky."
Having identified this business need, your IT Project Management as a Service partner can help by
supplying exactly the right resources that you need – when you and for as long as you need them.

As an exponent of PMaaS, I have been banging this drum for many years - the sector really does
have a solution for most IT Project deficiencies. Now that almost half of leaders are outsourcing
resources and at the same time talent shortages are trending down, it's not a huge leap to imagine
that the two are connected.

Take the PMaaS challenge - if you have a shortage anywhere in your portfolio - PMaaS will have the
answer.



Sources:
https://home.kpmg.com/xx/en/home/insights/2018/06/harvey-nash-kpmg-cio-survey-2018.html

The perfect IT project leaders in 2019 - optimistic realists who ask for help!



What could be easier than delivering an IT
Project?
You know what needs doing, you plan a budget,
you set a deadline, you gather together a team
and away you go - success is in the bag.

One of my Project Manager friends has a poster
of a beautiful ocean liner, under a cloudless blue
sky, on a calm turquoise sea with the caption -
"Full Steam Ahead". That is how IT Project
Management is, right?

Except, things go wrong. Calm turquoise seas
have a habit of turning into violent snarling
oceans, blue skies cloud over, there is a reason
why that beautiful ocean liner has an equally
beautiful row of lifeboats on its deck.

In IT Projects, the scope creeps, it turns out that you picked the wrong crew for your voyage or if you
picked the right ones - they leave, you miss a deadline and the ripple effect means you miss another
- and another, KPIs and actual performance become distant strangers ... lots of things can go wrong -
and probably will. It's how you deal with it that counts.
One of my big takeaway lessons helping teams achieve successful outcomes in their projects over
the last year is that few have the resilience needed to truly deal with the problems that can (and
usually do) happen along the way. Full steam ahead is a great mantra until you come across an
iceberg and it's the mantra you adopt at that point that will keep YOUR ship afloat!

So, with 2019 around the corner, I thought I'd share the lessons that I've learned over 2018 and
share just two changes that could make a huge difference to your project outcomes in the future.


1 - Be an optimistic realist - Develop a sense of expectation that things WILL go wrong - and be
COOL with that.
Expect failure and more importantly expect to learn from it - in fact, insist that failure teaches you
something.

Having achieved this, become an Optimistic Realist in your reaction. Let me explain.
I work with Project teams all the time who are optimists, always have been, their glass is always half
full rather than half empty and they expect good things to happen. Thing is, life and IT Projects are
not always like that. Sometimes things go wrong. All the optimism in the world won’t stop a project
with a creeping scope from running into serious trouble. I'm all for optimism but that won't stop
your board from restructuring the business and making your project redundant. To be an optimist
but EXCLUSIVELY expect things to go well can cause project teams to painfully crash and burn.

I've also worked with teams who are at the other end of the scale. Project leaders who are
pessimistic and are constantly asking "What could go wrong?" or "What if this decision turns out to
be a bad one?" You'd think that these types would be more prepared for the bad stuff, but it can be
just as painful. The pessimistic PMs also have a tendency to talk themselves out taking a risk that
could yield huge benefits or making a decision in case they end up getting it wrong.

I did an exercise with a Project Leader this year if you do catch yourself being pessimistic and saying,
"What if this goes wrong?" or "What if I get this judgement call wrong" you might want to try it too.
This PM's usual reaction to his natural pessimistic outlook was to try to play devil's advocate and be
an optimist who asks "OK, but what if it all goes right?" As this really isn't his nature, he never truly
listens to that contrary voice in his head and so doesn't benefit from its wisdom.
Instead, we carried on the "things going wrong" scenario to its natural conclusion because ... well,
things do go wrong. The darker outlook might be the one that does actually play out in reality.

This is where the Optimistic Realist position trumps both optimist and pessimist. Yeah, it might go
wrong but by continuing it on, and by giving proper thought to how you'd deal with a problem and
visualising solutions, you eventually come to a point where any potential problem just doesn’t
matter. The optimistic realist in you knows that you will sort it. The more you practice this idea of
things not going the way you planned and you being OK with that, the more the optimist in you can
dominate your feelings towards and reaction to problems. You start to process them as just part of
project life, as mundane and expected as the first cuppa of the day.


2 - Be REALLY cool with asking for help - EARLY

It’s true, your IT Project might not go to plan. By now though, you have learned to deal with it by
being an Optimistic Realist. Good for you. Problem is that your beautiful ocean liner is still heading
for that iceberg! You need all hands on deck to avert a catastrophe!

Often, project teams call for help too late. The Project Management as a Service sector is now so
evolved that I believe any challenge you may face is catered for. You need help transitioning your
project into the service delivery phase? You've got it! Need end to end, hit the ground running
Project Management Office? You've got it! Need a little extra experience when the complexity of a
project is beyond your in-house capability? You've got it!
BUT you do need to ask!

I've written before about why teams don't admit that there's a problem or that they are out of their
depth or that they need help. It's usually driven by some kind of fear or ego and that's
understandable, to a point. Admitting that you've bitten off more than you can chew with a project
that you've already started may seem daunting but it's better than waiting until you're two or three
months further down the line when the heat is really on! I think that "fessing up" that you need
extra resources or help, or that you haven't a clue what to do next is a strength, not a weakness. Get
help sooner rather than later, because later can quickly become too late!

One of my neighbours heard a knocking sound coming from the engine of her car and her solution
was to turn up the radio. Weeks went by and after a while, EVERYONE in the street could hear a
knocking sound. "You need to get that looked at!" we all said in a concerned, neighbourly way. She
turned up the radio some more. A couple of weeks back the knocking noise just stopped. It was
around the same time that her engine also just stopped, and she had to be rescued from the

motorway. Ironically, the queue that her broken down car caused made the travel reports on the
radio station that had helped drown out the racket! The moral of the story is that the most
opportune moment to seek assistance is as early as possible.
So, as I'm writing this in December, that's my Christmas present to you (if you're reading this at
some other time it's my Easter or Summer Holiday gift to you). Become an Optimistic Realist and ask
for help - early. I guess, right now, there will be projects that are in trouble - I hope that they're
being led by optimistic realists who anticipated the problems and are, at this very moment, dialling
up their favourite Project Management as a Service partner. These are the projects that will make it
to those Easter and Summer Holidays and beyond into service.

Happy Holidays!!

You have no new massages - A deep tissue lesson for IT Project Managers




My Project Manager friend, Colette came back from her
lunchtime massage today not as relaxed as she normally
does.

"Well that's a good way to lose potential business!" she
said.

The story she then told has lessons for project
management teams and as it is also quite funny, I will
share it with you.

Colette has been visiting a city centre salon for some
time. She goes there for beauty treatments, like nails
and waxing and things that, as a man, I don't fully
understand and as mentioned she also enjoys a
massage to help with the stresses of Project Management and being a Mum.
The salon is based in a hotel and has a gym and swimming pool attached. Colette has considered
joining the gym, mainly so that she can swim during her lunch break, but the pool is quite small and
Colette wondered whether she'd be able to achieve a sufficient work out in it. With this in mind, last
time she had a massage she asked if she could do a couple of lengths to check it out on her next visit.
The staff member said she didn't imagine that this would be a problem.

Anyway, today Colette went for her monthly massage and, before heading into the treatment room,
she mentioned the 'trial swim' to the receptionist who again said, "Sure, no problem!"
After a thoroughly relaxing 25 minute massage (that cost £35, I'm in the wrong job!) Colette got
changed into her swimming costume and was about to climb into the pool when she realised that
her towel was in the back of the car. However, but she had noticed people collecting towels from
reception so, dressed in her swimwear, she headed there. The receptionist obligingly handed over a
towel and Colette went back to try out the pool.

Only this time she was chased down the stairs by, it turned out, the manager who asked if Collette
was a member, or a hotel guest or there on a spa day. Colette explained she was none of these, she
was there for a massage and was just trying the small pool, as previously agreed, to see if it were fit
for her purpose before signing up to have £40 a month direct debited from her account.

The manager then said that as a customer "just here for a massage" (at £35 remember!!) this would
not be OK and that they would have to ask her to pay to use the pool.

Colette asked, "How much?"
The manager said that she would be charged the 'special' day rate of £10. (Or considering Colette's
intentions - £5 a length!)