Straight Talk On Project Management - Volume III

IT Project Collaboration. When 1+1 equals more than 2



"Be open to collaboration. Other people and other
people’s ideas are often better than your own," so said
comedian and actress Amy Poehler.
She's right.

I heard a great story this week that highlighted the value
of collaboration.
A radio station, I think in Australia (but don't quote me),
was brainstorming ways to improve its app. The
problem was that digital listening was on the increase
but a significant number of listeners migrating to digital
platforms were opting for an app that also rebroadcast
all their competitors' radio stations rather than just their
own. This obviously cut listeners out of receiving targeted messaging via the radio station's app - a
valuable revenue stream! It also meant they were noticing a drop off in early morning listening!

The meeting had the company's 'greatest brains' contributing insight and ideas and it had been
going on so long that the cleaner knocked on the door to ask if she could empty the bin in the
meeting room. At this point, the station director looked at his watch and started to wrap up the
meeting with a recap of the problem and the solutions they had come up with, from marketing
campaigns to increasing the number of ‘on air’ mentions.
"Add an alarm clock feature," said a voice from the back.

It was the cleaner. She used the collective app in favour of the radio station's because, as with her
old FM radio alarm clock, she liked waking up to the radio. The radio station's app didn't have this
feature. The app with all the other radio stations on it did.

After a long day of overthinking the problem, a solution had presented itself through an accidental
collaboration. They'd widened the brain power pool and perhaps found a really simple solution.
It's not just radio stations. In IT Project Management, how often do we get the same heads together
in the same room to solve new problems or challenges and end up with similar sounding solutions.
The thing is, in IT Project Management we are blessed with so many collaborative opportunities that
you don't have to wait for your cleaner to come round with the vac.

One of my clients, Steve, has developed collaborative project management to the point where it is
becoming a methodology of its own. Collaboratively they plan, coordinate and control some pretty
complex projects not just across departmental borders but national ones too. Everybody working in
the project has access to all the information about it, from tasks to budgets and resource allocation
to messages, from governance to documents and it gets updated in real-time too, so you have a real,
transparent sense of the state of the project at any given time.

The interesting thing is when working this way was first mooted, many of the project managers
kicked back and opposed the idea. "Too many cooks will spoil the broth," I recall one actually saying.
As it turned out, collaboration was the cornerstone of improvements in communication and
transparency and it has led to increased identification of potential pitfalls and problems and has
lessened their impact upon dependent projects across the entire portfolio. The 'broth' has never
been less spoiled!

Your own corporate architecture is a great resource of collaboration, but you would be limiting your
success potential if you limited your collaborative ambitions to people within your own organisation.
It's here where nerves tend to jangle a little. It takes a degree of bravery and a lot of trust to initiate
collaboration between your business, your customers, vendors, suppliers and partners, but it is so
worth it.

Effective collaboration creates a value network that delivers exponential learning and opportunity.
Indeed, Steve, the client mentioned above has collaborative arrangements, both formal and
informal, that span departments at his own firm, with his company's customers, with trusted
vendors and, of course, with us - his project management services advisory partner. The trick is that
everyone should benefit from the collaboration. Take our arrangement - we provide Project
Management as a Service solutions as our side of the collaborative deal. In return, we observe and
learn from watching those services transform his project delivery capability and as we do we bank
valuable knowledge that, one day, may help another client with another challenge.

Great value networks like this don't magically appear overnight. They can take weeks, months, even
years to create. Of course, your trusted Project Management as a Services partner can patch you
into collaborative arrangements and yield instant results, but it is down to you to make that first
move. You have to choose to collaborate.
Like my client, Steve says, "Start small if you're nervous about it. Offer your collaborative input to a
company to whom you're not connected. See what happens and how good it makes you feel. I
remember contacting the local train company and offering my thoughts after a commute one
morning. The email I got back was really nice but even better they implemented my suggestion and
sent me some free rail tickets as a thank you. The idea has since been taken on by other train
operators. Collaboration spreads."
Some of the Project Management as a Service placements we arrange are really small in the grand
scheme of the client's overall portfolio, but they can be as transformational as, say, placing an end to
end Project Management Office. The beauty of any PMaaS arrangement is that you can dial it up or
dial it down as needed.
In IT Project Management, collaborative working can never be too big or too small, in fact, to dispel
the notion that seemingly inconsequential collaboration has less value, I invite you to consider the
ingredients of a ginger cake.
In fact, say out loud now what the ingredients of a ginger cake are ... then ask the next five people
you meet to do the same.

How many started with "ginger"?
In fact, Ginger cake is mainly over 300g of mixed butter, golden syrup and plain and self-raising flour.
It's just a teaspoon of ground ginger that gives it that unique gingery taste. Your collaborative input
may also be compared as small as a spoonful of ginger, or a cleaner pointing out a missed

opportunity in an app, but it could also be the ingredient that provides the project with its unique
flavour.

It can be daunting, that first time, reaching out in a collaborative way. After all, business is
competitive, every instinct seems to scream "trust no-one!". The difference it makes though is
transformational, so this week, be that little pinch of ginger.

IT Project Portfolio Management. Less is more. Now isn't that ironic. Don't

you think?




My friend tells the story of a 4x4 SSV he used to own.
Famous marque, I won't name them, but not a cheap
car AT ALL! The vehicle developed a fault, the reverse
light wasn't working and there was a considerable delay
between changing gear and the dashboard display
registering the gear you were in.
He called the garage that he used to take the car to for
MOTs and servicing and asked if they could help. As it
was an electrical issue they advised they would have to
call in an auto-electrics expert at a cost of £50 then £50
per hour plus parts and labour from the garage - and
they couldn't guarantee that ‘Mr £50 call out’ would be
able to diagnose the problem.

My friend then tried the main dealer. They said that they WOULD be able to diagnose the issue, in
fact just from the call they were certain that they knew what the problem was. They wouldn't have
to call in a guy as all the diagnostic tools were on site, so it would be parts and labour. The estimate
was £500.

In the meantime, my friend had been given the number of a local 4x4 specialist, in fact, these guys
were specialists on this brand, both having trained at the main dealer before setting up on their
own. They also were certain that they could diagnose the issue and while they were happy for my
friend to bring his vehicle in, there was something that they wanted him to try.
"Put the car in reverse and drive for as long as it takes for the 'R' to register on the dashboard. Then,
put the car into first and drive, changing through the gears as each register on the dash and when
you get to sixth gear, pull over, turn off the ignition get out of the car and turn on the alarm. Then
unlock the car and call us back to tell us what happens".
Well, my friend thought these guys were having a laugh but did as they said. Guess what? Within ten
minutes the reverse light was working and the gears registering as they should. He called the garage
and was told that this is probably what the main dealer would have tried first (and charged £500
for). It was the car’s equivalent of a hard reboot.

The relevance of this story to IT Project Management is that sometimes the fix you need is a really
quick one, sometimes you don't need to embark on an expensive voyage of discovery, sometimes
you just need someone who won't rip you off to point you in the right direction.
The above story came to mind when I was asked to help with an IT Project recently and having taken
a look, I turned down the work. The reason was that this project, that the in-house team had been
struggling with, wasn't a project at all - it was a software purchase. I'm not even joking, the thing
that they had been trying to build was available as a ready to run a bit of accounting software.

BUT ...

They had received quotes from a software firm to build the desired package from scratch.
They had also sourced a proposal from a project management services firm complete with costings
for 'as a Service' resources that would complement the in-house team's efforts to deliver the existing
project.
Then there was me, suggesting that they do the equivalent of sticking their project in reverse, drive
up the street and flick on the alarm.

One of the common characteristics of firms with high rates of project failure is that they have too
many projects on the go at once. There's nothing wrong, in principle, with having a HUGE portfolio
of projects if you have the resources to deliver or you have a great Project Delivery and Project
Management as a Service partner - but I urge you to do the "Is this even a Project" test.
Over my career, I have found that the word project is as misused and misunderstood as the word
"Ironic" is in the Alanis Morissette song of the same name. If it rains on your wedding day, that’s a
meteorological coincidence, not ironic. If you win the lottery and drop dead the next that's just
remarkable good luck followed by bad luck. If you meet the man of your dreams and then meet his
beautiful wife, that's not irony, that's just sickening. Maybe the irony is that the song called “Ironic”
contains no irony.

Anyway, I digress.
The thing is, that a lot of what gets called an IT Project really isn't a project at all; but because it has
been labelled thus and allocated to the IT Project team it will devour resources, water down the
potency and distract the attention of the Project Management Office and delay actual IT projects
within the wider portfolio that were destined to deliver real business value.

Now that, Alanis, IS ironic. Probably.

I used to think that this was mainly an issue in the public sector where pressure on budgets may not
be as much a matter of life and death but recently, I am increasingly seeing ‘non-projects’ draining
the resources of private sector organisations as well.

The PMI’s Project Management Body of Knowledge defines a project as "a temporary endeavour
undertaken to create a unique product, service or result. Furthermore, it is "temporary in that it has
a defined beginning and end in time, and therefore defined scope and resources" and "unique in
that it is not a routine operation, but a specific set of operations designed to accomplish a singular
goal".
That's pretty neat definition.

In his article for CIO.com, Antonio Nieto-Rodriguez writes "Set some clear and objective criteria of
what is a project (changing-the-business), and what should be considered as day-to-day activities (or
what I call, running-the-business)."

I would also consider the size of the project's budget, impact on the business (how many
departments will be affected or benefit from the 'project', the duration allocated and expected
delivery schedule (is anything less than six months really a project?) and how aligned with the
strategic goals of the business the project is.

The project that I recommended was instead a software purchase had been allocated a three-month
lifecycle, a few thousand pounds budget and it would impact one (maybe two) business units. They'd
taken it on because it seemed like an easy deliver. Get in, get the gold, get the credit for another
project delivered. In reality, it was over time, over budget and all the while diverting resources away
from the rest of the project portfolio and projects that would affect real business change.

To conclude, budgets are not blank cheques these days. The pressure on IT Projects to deliver return
on investment is greater than ever and failure rates are as high as they have always been. It's time
for us all to act more selfishly and for the good of strategic business, delivery focus on the projects
that matter. If you struggle to identify the difference between these sometimes an independent pair
of eyes, taking a fresh look can see things that you can’t – and it’s OK to ask for that help!

The deliverables of 'non-projects' can still be attained but with simple purchases or simply, as
Antonio Nieto-Rodriguez says, running the business.

So, Let's stick to only calling them projects when they are projects. Otherwise, it's like ten thousand
spoons when all you need is a knife … isn't that right Alanis?


Sources

https://www.cio.com/article/3031636/leadership-management/why-less-is-more-with-project-
management.html

https://www.pmi.org/about/learn-about-pmi/what-is-project-management

IT Projects. Do we actually ever learn lessons learnt?



We record 'lessons learnt' as part of the project
management process but do we actually learn from
them?
Recent experience and the number of projects that fail
to deliver suggest we could probably all do better.

It is worth considering this for a moment ... Do you
action the learnings or do challenges keep resurfacing
time and again? Do you keep noting down the same
points each project?
It makes great sense to learn from lessons and
instinctively you know this. Remember when you
learned to ride a bike? How did the first attempt go?
And the second and the third? You adjusted your approach after every wobble. Every grazed knee
was a learning opportunity. Eventually, you sped down your street with the cheers of your parents
ringing your ears ... before mistakenly pulling hard on the front brake and flying over the handlebars!
And I bet you only did that once! You learnt from all your mistakes - you are a natural!
So, why do we not always learn from our lessons learnt?

1 - Learning lessons are seen as dwelling on negatives
The Project Management industry needs a wholesale rethink on this. One of my clients has a weekly
meeting to actively learn lessons and every attendee used to dread it! I'm not surprised, it was half
an hour of dredging up mistakes from last week first thing every Monday. Not very motivational!
I suggested refocussing the meeting so that it also included successes that should be repeated. Huge
transformation! Some of the best lessons that we can learn are not from mistakes we make, they
come from the things that we get right. Lessons can be both positive and negative, but many outfits
still draw most of their lessons from painful rather than joyful experiences.
2 - Lessons fall into a knowledge black hole

One of the greatest issues is that lessons get recorded but then filed away in a drawer never to see
the light of day again!
Does everyone on your team know where to even access this project knowledge bank?

If they do are they inclined to read it? The way we document project lessons is often dull! Where are
yours? On a sheet of A4 paper in a file or lost somewhere in your company's cloud as a Word
document. What could be less inspiring?!

Why not record a video blog or an audio recap of lessons that have been learned? On your
smartphone, you could make a very engaging bit of content in no time at all. One of my Project
Leader does this, shoots a quick video, and uploads it to Yammer every Monday (even includes the
hilarious out-takes!) and engagement with this knowledge resource has "gone through the roof".

3 - Everyone assumes lessons aren't theirs to be learned

I've lost count of the number of firms I've consulted with who are struggling with a problem that
someone in the same organisation has already solved. Most recently I was told by a Project Manager
that although he was aware of a database of lessons learnt, he only ever read those that were
directly relevant to his own projects. And yet here he was battling a challenge that six weeks before
a colleague had overcome and thoroughly documented. What could be more relevant? I did a
keyword search of the database and found the answer in seconds so it's not a huge time investment.
I'm a bit of a geek when it comes to lessons, I love to hear, read and learn from other people's
experiences - you never know when a nugget of information might come in handy.

4 - Too busy!
I get this by the way. There's a lot of stuff to do on your "stuff to do" list and, frankly, half an hour in
a meeting about lessons learnt doesn't tick anything off your task list, in fact, while you're there a
stakeholder has probably sneaked a scope change request into your inbox.
My friend is a gardener and one of his clients probably has the largest collection of immaculately
shaped trees, hedges and bushes. Maintaining them is a long day’s work and on that day, he arrives
early and leaves late but instead of getting stuck straight in he spends half an hour or more
sharpening his shears. It pays off in the long run.

I compare this to spending half an hour reading lessons that have been learnt, you should never be
too busy to sharpen your metaphorical shears, remember Gandhi said, "I have so much to
accomplish today that I must meditate for two hours instead of one."

You're never too busy to improve yourself!

5 - Budgets are tight - can't make a justifiable case for "luxuries like navel-gazing"
This was an actual excuse I heard for not learning lessons from previous project experiences - a PM
told me that he couldn't justify the cost of "the downtime".

What a sad state of affairs that time spent learning how to work better and smarter is considered a
waste of money. I guess there's no tangible return on this investment of time to prove that it is time
well spent. However, I do know that getting things right the first-time costs less than having to do
them again or having to parachute firefighting talent in to help fix problems later. Don't think of self-
improvement as a luxury, it’s essential and certainly don't think of it as navel gazing!
6 - Too polite!

This actually happened. I consulted on a project recently and as part of our thorough initiation
procedure, we conducted interviews with everyone working on it. The project was over budget and
missing key milestones - so why was it so late? One chap, let's call him 'Steve', remarked that one of
his colleagues (let's call him 'Geoff') was working on something that could easily be bought in off the
shelf for a fraction of the development costs - and this wasn't the first time Geoff had wasted time
and money in this way - this had been flagged up in the debrief from the last project.

I asked Steve if he'd shared his concerns up with Geoff? He said he hadn't - as he didn't want to
cause a scene.

"If you saw Geoff walking down the street, lost in his iPhone and it looked like he was about to walk
down a road-works hole. Would you be afraid of offending him by grabbing his arm and swerving
him from danger?" I asked.
"Point taken," said Steve and went to talk with Geoff.

Honestly, we're all grown-ups! It's OK to hold each other accountable! If you see someone repeating
a previously agreed "lesson to be learned" you have a responsibility to say so.

7 - The lessons are too vague
I remember seeing a debrief note with six lessons that should be learnt. In the bullet point list, the
project leader acknowledged that scope had crept, the budget had been blown, the project was late,
morale was low, communication was poor and business case wasn't clear. All of these areas would
have to be improved upon. But how? The document didn't drill down with any thoughts on how they
would improve governance to avoid creep or how a contingency budget should be allocated so that
future projects avoided dipping into the red!
So, drill down a bit and leave some thoughts for your future self and successors on how to avoid
making the same mistakes again. To be fair sometimes you don't know how otherwise you probably
wouldn't have had a lesson to learn in the first place - you'd have just done it the better way first
time around!

Often, an independent pair of eyes can help with this. Your Project Management as a Service partner
can advise on best in class, cutting-edge solutions for most challenges to help avoid them in the
future.

In conclusion, I guess we have all been guilty of not learning lessons. The trouble is that once or
twice easily becomes a bad habit and bad habits cost money.
I have a friend in the States with a client that he says is a repeat offender. "These guys are putting
my kids through college," he joked in a recent email. "Every project we parachute project
management resources into rescue them last minute and because of the last-minute nature it costs
them heaps more. After every project we make the same recommendations, better planning and
more time working out project requirements, earlier deployment of Project Management as a
Service (PMaaS) resources (which is cheaper in the long run than firefighting). Every time they nod
and file the recommendations away, a month or two goes by and we get a call asking for us
parachute in talent again."

Athlete Vernon Law is reported to have once remarked that "Experience is a hard teacher because
she gives the test first, the lesson afterwards."
The truth is that in IT project management testing times are almost guaranteed, what makes
challenging projects more bearable is knowing that they come with a valuable by-product ... you
come out of the other end having learned a hell of a lot. Let's not waste that!

PMaaS – The Golden Gate for IT roject instant gratification




What is your reaction to reading these three words …
slow internet connection? I know! Me too. Waiting just
a few extra seconds for a page to load can feel like
forever!

Smartphone apps have eliminated the need to wait for
anything, from a taxi, to a table at your favourite
restaurant to a date. On Netflix, you can start
streaming a movie or a TV boxset in seconds.
Researchers at UMass Amherst recently revealed the
length of time folks are willing to wait for a video to
load. Computer science professor, Ramesh Sitaraman,
examined the viewing habits of 6.7 million internet
users - guess how long viewers were willing to wait?
Ten seconds?? Five? No, staggeringly TWO SECONDS!!

Sitaraman said, “After that, they started abandoning. After five seconds, the abandonment rate is
25%. When you get to 10 seconds, half are gone.”

We want everything instantly and this desire can bring us exciting possibilities.

I was thinking about this when we came back from a holiday in the U.S. and instantly (within 2 hours
of landing!!!) I was able to go through the entire trip with my mother-in-law. We were visiting family
and excitedly sharing the tales of our adventures - it was great to be able to bring the tales to life
with pictures and show her what her grandchildren had experienced. Back in the day, I'd have had to
wait until the chemist opened and then wait for the film to be processed … even the 'express' one
hour option feels like an eternity!!

We live in a world of 'instant gratification' and the IT Project Management world is no exception,
only in our world failure to instantly deliver can be more costly than someone missing on the latest
cute cat video. It can mean failure to deliver key strategic business goals, it can mean losing ground
on your competition, it can mean less relevant and up to date service delivery, it can mean stressed
out project sponsors and end users and it can mean missing out on your potential best results and
performance.

‘Instant gratification’ is changing expectations, both in our personal and professional lives and
selecting the right new tools is the fastest way to deliver it.
A good example of this was in San Francisco and the iconic Golden Bridge shot.

As you probably know, the Golden Gate Bridge is shrouded in mist 90% of the time and on the rare
occasion that it is not, it is very popular with tourists who want to experience the landmark and take
that all important photograph. Unfortunately, that means that the viewing area car parks often get
closed due to the influx of visitors and the surrounding roads become clogged with stationary traffic.
We visited on one such day – the sun was shining, and the tourists were out in force. We

approached the bridge and found that all of the car parks were full and it was not possible to stop
the car – disaster!

At least, it would have been a disaster if I was using old technology. My chances of taking a
photograph would have been somewhere near zero back then – I was never fortunate enough to
own a high-end SLR camera capable of shooting pictures whilst moving. Instead, my compact camera
had required a stationary, stable platform from which to shoot. The car I was in was moving so all of
this would have been out of the question. Then, I'd have been anxious about wasting any of the 24
or 36 exposures that the limited film allowed.

Nowadays though modern technology, my iPhone 10, meant that I could hold the phone out of the
window and ‘click’ all the way down the road. I took 50+ shots knowing I could discard any pictures
that I didn’t need, just selecting the best one, the one that met my brief. Check out the result, by the
way, cool picture eh?!
Instant gratification!

Then it was back to work and I was in the process of showing off my pictures to my colleagues, who
WERE very, very interested when the phone rang. It was a client with a problem - an exciting new IT
Project WITH an exhilaratingly tight delivery schedule AND an existing project portfolio that
subsequently would be stretched.

Even a team as adept at Agile project working as this one had real concerns and, looking at the new
project’s schedule and the existing workload, it was easy to see why.

The project sponsors, just like the rest of us, were impatient, less tolerant of allowing time to elapse,
they didn’t want to hang around and wait to see results, they wanted to see the benefit of their
investment instantly! They also didn't want the other projects to suffer.

Back in the day, you would have to rely upon and stretch your permanent in-house resources, or
gamble on contractors to deliver. I thought of myself capturing that shot of the Golden Gate Bridge,
the old project tools were the equivalent of that compact camera - the chance of getting the desired
result was slim.

No, if instant gratification were needed it would depend on instant results and, in turn, that would
depend upon instant guaranteed top performance - solutions that would hit the ground running.
So, we quickly turned our thoughts to the Project Management as a Service (PMaaS) sector.

The PMaaS universe, like the functionality of your smartphone, is constantly expanding and evolving.
I mean, my first iPhone would have struggled to get that Golden Gate Bridge shot (remember how
everyone had white eyes in photographs that needed a flash?!). Similarly, the Project Management
Services market of ten years ago might have struggled with this challenge.

Not now though, within what felt like seconds we had an end to end Project Management Office
proposal drawn up complete with ready to go resources. The existing portfolio would be unaffected,
the new project would achieve all the instant deliverables on time and there were no overall cost
implications.

With PMaaS you don’t have to wait to see if 'you've set your equipment correctly' and hang around
to see results. There is no gambling on contractors or stretching of your permanent resources, with
the right partner – you can have instant access to proven experience and skills.

The desire for instant gratification is only going to intensify. Retailers are sensing potential financial
gain - same-day delivery will soon become a common option at the online checkout (my friend Sue
in the USA placed an order with Amazon at 10.30am and it had been delivered to her Boston home
by the end of the working day - all for less than ten dollars!)

The point is that these retailers are leveraging our impatience and profiting from it.

In IT Project Management, PMaaS allows us to do the same.




Source:
https://www.bostonglobe.com/lifestyle/style/2013/02/01/the-growing-culture-impatience-
where-instant-gratification-makes-crave-more-instant-
gratification/q8tWDNGeJB2mm45fQxtTQP/story.html

The rise and rise of Hybrid Project Management methodology




One size hasn't fitted all in IT Project Management for
many years.

However, five years back a project team using Waterfall
on a project that was more suited to Agile might have
got away with it. I mean, perhaps they wouldn't have
leveraged all the potential, they may, for example, have
been slower coming to market than they would have
with Agile but broadly speaking they could deliver a
successful project.
Now, as projects become increasingly complex and
more closely aligned to business goals, choosing the
right methodology REALLY makes all the difference.
The choice of project management approach (how a project is planned, executed and delivered into
service) can have a huge strategic impact. Choosing the wrong project management methodology is
often mentioned as one of the main reasons why a project has failed. In these cases, teams will
usually have opted for one single methodology and stick with it as an end to end solution. Actually, a
hybrid combination of elements from a multiple of methodologies might have worked better.
Project management methodologies are often selected at a broader organisational level with little
thought given to the specifics of an individual project – that has to change.
Successful teams are finding that it's not just that one methodology won't suit all projects in their
portfolio, it's moreover the case that one approach is not best fit for all the individual elements of a
single project.
A recent report from PMI points to growth in the volume of IT Projects being delivered using hybrid
methodologies where you take parts from different methodologies, elements that have a proven
track record of securing successful delivery and combine them to create a more efficient delivery
system. This backs up what we are seeing and the rise of hybrid methodologies in IT Project
Management is very exciting because the potential for innovation grows exponentially!

This growth in adoption has resulted in a growing demand for Project Managers with the ability to
apply a varied approach but they cannot always be found by looking in the usual places. Many
businesses are looking to a trusted Project Management as a Service partner to provide a more
diverse outlook. The PMaaS market, by its nature, has an abundance of talent and solutions ready
hit the ground running.
The problem is that often methodologies become hard-wired into the way a project team or
individual works or the methodology becomes such a comfort zone that teams are reluctant to try
new approaches. I once had to referee a heated debate between two project managers who were
coming at the selection of methodology from very entrenched positions. It was like they were
discussing their religion or their allegiance to football teams rather than how to get the best out of
an IT Project.

A Project Manager I know called Kev compares this entrenched position to his leisure activity to
illustrate the limitations. Kev is a triathlete and he says that sticking blindly to a methodology is like
identifying that the way to win one part of a race is the key to winning them all. "The bike for
example, would help you speed past the other athletes in the running bit, but then you'd enter the
lake and sink like a stone."

He's got a point.
There's a reason why you pack trainers for the running part, a wetsuit for the swimming bit and
Sudocrem for the cycling! They work best for those individual disciplines but as total solutions for
the end to end race they'd be, at best, less effective or, at worst, useless.

If this sounds familiar, from an IT Project Management perspective, using PMaaS resources can
certainly help.

I saw a client apply this thinking to an IT Project recently, using PMaaS talent and a hybrid of (mainly)
Waterfall and agile. They used waterfall to map the project's path, starting with establishing the
project's requirements and specification and through the development, testing, and delivery stages.
For all of this Waterfall was king but then they distilled the project down to its constituent
component parts and found that for these Agile was more effective. Agile was deployed to develop,
refine and then release each individual component and, because IT Projects are like Russian dolls,
most components had a layer of components within. Agile was effectively used to deliver these too.

The use of Agile clearly accelerated delivery of the component parts and played a huge part in
improved quality standards too. Each component part of the project was 'chunked' into tasks, given
a timescale and Agile was used to complete and then release each component, in most cases to be
used as the foundation for the next phase of component tasks.

Waterfall was used to knit them all together, manage dependencies, co-ordinate 'high level' tasks
and deliver the overall project. Using a hybrid of methods, the client delivered a higher quality
project to market and much faster than anticipated.

Even better, during the course of the project there was disruption in the market from a competitor
and, thanks to their use of Agile, the team was able to potently react and respond.

My colleagues and I have written many times over the years about the need for more joined up
application of project methodologies and I am thrilled that use of 'hybrid' approaches is on the rise.
Letting go of tried and tested methodologies and mixing things up is a big step away from the
comfort zone for many but the results are so worth it.

When an IT Project isn't an IT Project, engagement soars





Calling an IT Project 'an IT Project' may be doing your
project a disservice.



"This is NOT an IT Project."
This was the opening line of a pitch that I heard earlier
this year ... it was a pitch for a green light for an IT
Project! Brave start!
It got me thinking.

In many ways, very few IT Projects are IT Projects these
days.

They are organisational change projects, they are
operational streamlining projects, they are business strategy delivery projects, business alignment
projects, etc, etc. It just happens that these things are being delivered through the medium of IT. So,
when IT is at the core of your delivery strategy or your business model, calling an IT Project 'an IT
Project' may be doing it a disservice.

My PM friend Malc makes this point by telling the story of his first IT Project and his most recent.
The first, back in the day, was to upgrade desktops from clunky old DOS to the latest cutting-edge
Windows OS, create a network of linked PCs across the firm and replace dot matrix printers with less
noisy inkjet ones that didn't chew up your report the moment you turned your back. Now THAT was
an IT Project!
His latest project also incorporated an OS migration (to Windows 10), it also improved connectivity
between users but this time they were in different cities (not just offices) and many were tablet
based and even BYOD (Bring Your Own Device). Oh, and printers became a thing of the past as one
of the project's aims was paper-free working. On the face of it such similar goals, yet this latest
project was seen as a business change project!

The first project was carried out in almost stealth like conditions overnight (no-one knew or cared),
whereas the latest project was undertaken in a blaze of internal communication and end-user buy-in
where everyone was really quite buzzed about the benefits and difference change would bring to
them and the business.

It makes sense if you are the Finance Director which are you most likely to buy in to? An 'IT Project'
or a Project that delivers faster and more accurate invoicing and better debtor reporting? If you are
the Sales Director - 'IT Project' or a Project that delivers real-time sales and insight into the activity of
your account managers? Transport Manager - 'IT Project' or Project that tracks your delivery vans
and analyses traffic conditions to predict delivery times and automatically updates customer-facing
systems? These business outcomes are sexy whereas the IT, effectively the means to the end, well,

you have to really love IT the way we do to get excited about that! That's OK by the way, I zone out
when my Fleet Manager friend starts talking about his lorries!

Awareness of this creates a HUGE opportunity.

Plenty of IT leaders that I talk with have identified that when leaders of other parts of the business
believe that a project is IT-led, they are less likely to be fully engaged. They are more likely to take a
back seat approach, treating IT as a back-office function that will deliver a solution to their
challenges with some mysterious piece of software or hardware that they, themselves, will never
fully understand.

However, when the project is operationally led, they tend to engage better and earlier.

When the business case 'why' is clear for everyone to buy into from their own perspective, it is
amazing how much more they are more willing to do so. This is true when seeking an initial green
light right through to the all-important engagement that can keep a project alive.

So far, so good.
The IT Project that wasn't an IT Project that I mentioned at the start got its green light and the IT
team went about allocating resources and responsibilities the way that they always had.

It was at this point that I wondered if you could take this whole 'not an IT Project' idea a whole step
further. Thing is, if you declare that your project isn't an IT Project and then treat execution of it
exactly the way you have every IT Project ever, it might be not too be long before it starts to have a
feel of the emperor's new clothes about it. I mean, it all felt a bit superficial, like a marketing slogan
rather than a statement of intent, and I feared that end-user expectations may not be met when
suddenly the IT guys appeared and totally took over. Next time the wider business may not buy it!

The CIO and I began to play with this idea and an exciting new opportunity space for true
engagement opened up.

Instead of just operationally owning the project and then having it IT-led, what if it were also
operationally led? What if your project teams were staffed by operational talent as well as IT talent?
What if the metrics for success were from an operational perspective rather than an IT one? An
operationally anchored, IT-supported project would surely attract greater engagement across the
wider business and, because actions speak louder than words, there may be a ripple effect on buy-in
for future IT projects too.
Here's what the CIO came up with.

First, he fired himself. He appointed the CEO as 'Project Chair' - the executive owner of the project.
The CIO told me, "Immediately, the project had extra operational oomph! More than any previous IT
Project had. The CEO allocated responsibilities across the departmental heads that were relevant to
their daily routines and disciplines. The prospect of operational consequences that would be felt by
each department head really focussed minds and we discovered that 'really nice to have' extras
came to mind that could be incorporated without causing harm to the project's budget and timeline
or noted and prioritised as future project goals. The CEO tasked each leader with establishing how
success would be measured, and as each metric had an operational basis there was clear business
case benefit."

The business also discovered a number of "wrong problems" it was trying to solve when it came at
them from a business mindset rather than an IT one. They were able to cross off some project
objectives that the IT team had incorporated into the plan because the business users said they were
unnecessary.
Now, I'll let you in on a secret. None of this is REALLY ground-breaking. At Stoneseed our client-side
approach to IT-supported business change has always meant business led IT Projects. It was really
nice to plant a seed in the head of a CIO and watch a strategy, that is effectively one of our business
models, grow organically at this organisation.

To conclude, in the next era of IT Projects, this is how more and more business change will be
executed - operationally led and IT-supported. Operational and IT structures that have reached a
maturity to support each other should enjoy easy wins, and those that are playing catch up can take
comfort in the many and varied project management services that are available.

The Project Management as a Service sector can provide anything from individual talent to end to
end Project Management Office and a Project Services partner with their business head screwed on
and a keen sense of your unique needs could be your greatest ally. I look forward to hearing about
and maybe helping with your next 'not IT Project'.

When riding your IT project cycle - do you know how or when to get off? The

value of closeout





When discussing Stoneseed's Project Management as a
Service (PMaaS) solutions with clients I am always
intrigued by the way they manage IT projects. In almost
every case, the client will walk us through some form of
lifecycle, typically composing four stages that can be
loosely labelled along the following lines ... initiation,
planning, delivery, closure.

The terminology and the number of phases may differ
slightly from client to client but, broadly speaking, most
follow a similar model.

As this is a cycle, the really interesting part of the
discussion for me is how this is applied to a project in
real life. Crucially, how does the lifecycle map onto a
project timeline? Where does a project start and finish?

In my experience, project organisations are reasonably good at defining the start point, that stage in
the cycle where an idea or concept actually becomes a project.

Strangely, where many organisations are not so good is defining the endpoint.

They know how to get on and how to ride their project cycle, but many don’t know how or when to
get off. This means that they either ride off into the distance (never-ending projects are becoming
more common) or they lose balance and crash in a heap of twisted pedals and bent spokes.

Why?
There are usually a number of reasons that blur the view of project teams at closeout.

1 - Often resources are tight, so the project team have to quickly move onto the next project upon
'completion'.
2 - Maybe the closure phase is seen as less important than the tangible delivery, which is complete
by the stage that closeout is beneficial. This can be from both the viewpoint of the project team and
also the client organisation. It can be like reviewing a car journey when you've arrived at the
destination. What's the point, right? But what if there was another road you could have taken? What
if the motorway could have shaved an hour off the journey? What if the scenic route could have
provided a more picturesque and inspiring view from your driver's seat.
3 - Attention can go AWOL! Especially after delivering a difficult project! Team members can treat
closeout like a footballer might treat a post-match TV interview. That is, something that they have to
do but also something that doesn't affect the result (N.B. In IT Project Management this bit of post-
match analysis can totally affect the result!!!)

4 - Sometimes, a team fails to plan the closeout phase and is forced to attempt to both plan and
execute this phase at the same time which can be like herding cats!

5 - Often, team members begin to leave the team before closure phase is completed due to a lack of
understanding of their role in the closeout.

6 - Sometimes, the closeout phase surfaces unresolved issues, unsatisfactory deliverables or
uncompleted work but the team has started to disband and so it is left to the project manager and a
smaller staff to resolve issues that they themselves may not have had a hand in creating.

7 - Usually, there is a lack of ownership for this phase. It's often not seen as a 'sexy' part of Project
Management, so no-one wants their name attached to it! As one PM friend puts it poetically, "My
parents run a pub, their name is above the front door as you enter and not above the door to the
toilets!"

... by the way, often it is a combination of these reasons that lead to this closeout step being either
less effective or discarded altogether.
I am a big advocate of the closure phase, often considering it a crucial part of the actual execution
phase. A time where you gather lessons learned, ensure projects are handed into BAU in a
structured way, close down budgets, etc. Without this closeout phase, the project team cannot fully
move onto the next project, not benefit from experiences on the project that can be used to
improve moving forward. As the PMI puts it, "Failure to conduct thorough project closeout could
potentially (a) put the organization at a considerable amount of risk, (b) prevent the organization
from realizing the anticipated benefits from the deliverables of the project, (c) result in significant
losses to the organization, and (d) undermine the project manager and project management team's
credibility."

I believe that the closure phase is becoming increasingly even more important.
Historically, the closeout phase was the time where all aspects of the project would be agreed to be
concluded to the satisfaction of your client or senior management. After closeout, key team
members would leave so this would be a valuable last chance to learn together. The project
manager’s role in this closure phase was to ensure that all facets of the project were properly
concluded. Also, at the end of a project team members can sometimes lose focus and discipline
(after all you've delivered the project) so it would the PM's job to help the team retain its attention
for these final (important) activities.

In reality, all too often, the closure phase is considered a tick box exercise which is undertaken at
some point long after the cut and thrust of project delivery has become a distant memory. That
needs to change. Not just because it is a sensible stage of any project delivery but because I believe
that the project timeline is changing – it is getting longer.

In a recent blog I talked about the importance of ‘Marrying IT Strategy and Projects’, we focused on
the need to define outcomes and how a business case helps with this alignment. In that article we
highlighted the definition of a business case as “justification for pursuing a course of action in an
organizational context to meet stated organizational objectives or goals.” the words to focus on, are
organisational objectives and goals. In other words, the principal reason for any project is that they
help to meet the goals of the organisation, seems sensible enough, doesn’t it?

There is a challenge here though and it is all down to when project benefits are typically realised.
Moreover, this tends to be long term. Consider an ERP implementation that is undertaken to

improve efficiency and information availability, at what point are these benefits realised and at what
point can they realistically be measured? The answer often is at 'some point' long after the project is
‘officially’ considered complete. It is only when new technology becomes embedded (which takes
time) that the true benefits are seen within the organisation.
I believe therefore that, as strategy and project delivery become more aligned, the focus on benefits
and their realisation (both short and long-term) will remain with the project team. The natural
consequence of this is an extending of the delivery and/or closure phases. Project teams will own
the benefits realisation and, as this will not become clear until 'some point' after implementation,
the time that a project team needs to be available to work on a project is stretched along the
timeline, adding further pressure to over utilised resources.
This is where Project Management as a Service comes in.

Transition into service is the part of the process where project managers report the greatest 'value
leak' - to return to that football analogy from earlier it's like setting up the perfect goal only for the
striker to squander the chance by blasting the ball over the bar! You probably have tight governance
throughout the project life cycle, but how well you finish your project? It is key to leveraging
maximum business value! How well defined are your processes that move your project into BAU? Is
your service delivery capability geared up to maintain the project deliverables? Through Service
Delivery Assessments we are often surprised at how otherwise clued up clients are leaving this to
chance - even the most capable project teams often find there is huge value in 'buying in' delivery
management services.
The solution to literally every issue we have discussed here (and many others that we didn't have
space to cover) can be found when you work with the right PMaaS partner. As project timelines
become more stretched it is increasingly important that project teams find innovative ways to
resource them. As projects become more complex and business case aligned, and as realisation of
benefits becomes more of a future event it has never been more important to define endpoints and
measure success in terms of actual business gains - no matter how long after delivery they come to
fruition.



Source
Aziz, E. E. (2015). Project closing: the small process group with big impact. Paper presented at
PMI® Global Congress 2015—EMEA, London, England. Newtown Square, PA: Project Management
Institute.https://www.pmi.org/learning/library/importance-of-closing-process-group-9949

Which IT Project Methodology? Waterfall – why and why not?



In a recent 'flyover' of IT Project Methodologies, I
promised that I would return to each individually and
assess their advantages and disadvantages. In this, the
first in a series of posts, let's take a look at Waterfall.

Waterfall. What Is It, When Should You Use It?

1970 was quite a year for firsts! The first jumbo jet to
land in Britain, a Boeing 747, touched down at
Heathrow Airport; the first Glastonbury Festival was
held, as the Worthy Farm Pop Festival; eighteen years
olds were allowed to vote in a UK General Election for
the first time; and in a paper by Dr. Winston W. Royce,
the phases of the Waterfall methodology were first
formally published (although, like Glastonbury, it wasn't
immediately called that!)

The Waterfall method has been the go-to approach for Project Teams throughout much of my
career, but I am noticing that it is becoming less popular as teams opt for more agile models. It is,
however, still relevant today and can bring you massive benefits.

Here’s what I wrote in my flyover post ...

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

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

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

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

I asked some IT Project contacts for their thoughts ...
What advocates of Waterfall say

ORGANISATION - It forces you to be organised. "Waterfall methodology forces discipline on you and
your project. If you struggle with structure, waterfall is the best model for nagging you into line."

GREAT FOR LESS STABLE TEAMS - It's great for more fluid teams. "Our projects team members come
and go, the structured documenting that waterfall requires is ideal for incoming staff so that they
can hit the ground running.
EASIER TO FOLLOW - Following on from the above, everyone knows just where in the life cycle of
the project they are - at every stage. This allows project managers to be more organised and to keep
the process flowing.
MILES AHEAD FOR MILESTONES - Perfect for milestone and deadline driven projects. The linear
structure of waterfall lends itself to projects and teams that are suited to ‘milestone led working’
due to the ease with which "a timeline for the whole project can be drawn and easily marked into
stages. This adds clarity to the project that makes communication and understanding across the
team fairly easy."

EARLY CHANGES - Great for projects which benefit from (or have a need for) design alterations early
on in the process. Changes can easily be accommodated early on in the lifecycle (although,
admittedly, it gets harder further on).

BETTER QUALITY OUTCOMES - Waterfall often delivers a better end product. Each stage of the
waterfall process is effectively spent debugging, you don't move on until the stage you are working
on is acceptable so if you follow that logically to the end conclusion you should finish up with a
product that is perfect.

LESS NEED FOR MICROMANAGEMENT - The 'rules' of Waterfall sort of look after a lot of your
management needs - you don't move on until you've completed each step. "It actually saves me
time managing in the project because the rules are well established and understood which allows
me time to work on the project, taking a helicopter view of the project rather than getting bogged
down in little details.”
What Waterfall's detractors say

CHANGES ARE DIFFICULT – Although it may accommodate early stage changes, because Waterfall is
a set of sequential steps, once you have moved on, alterations to previous elements of the project
are harder than with more agile solutions. Not impossible! We joke that one PM friend is so adept at
swimming back upstream using waterfall he must have been a salmon in a previous life. The truth is
that he has adapted Waterfall so it is almost a hybrid of Waterfall and Agile and the key is an
awareness of how a retrospective change to a previous stage will affect successive stages and
making a judgement call based upon that. Also, any changes that are made have to meticulously
documented.
TRADITIONALLY, LATE TESTING MEANS ERRORS ARE FOUND LESS QUICKLY - Some Waterfall users,
following a traditional template, say that late testing of a project means that problems are found
later and are therefore harder to put right. The workaround for this, as hinted earlier, is to test at
every stage before moving on.
LESS TRANSPARENT FOR STAKEHOLDERS - Waterfall is a bit of a closed shop! Waterfall is great for
keeping your team up to date but those using it tend not to share progress with clients and
stakeholders. One PM put it like this, "If you're building a house, when does it start to look like the
house your client is imagining? Not when you dig the foundations, not when you lay the first bricks,
it isn't until the late stages, when the roof goes on or you hang the doors and windows that it finally
becomes a house. It's the same with Waterfall IT Projects, there's no point sharing meaningful
information about your project until close to delivery, to do otherwise is like taking a builder

showing their client the holes they've dug for the foundations and asking, 'What do you think of your
house?' - waste of time."

The Waterfall methodology has attracted lovers and haters since day one. The fact that almost 50
years on we are still using it and other new methodologies have emerged over time to address its
flaws suggests that it as relevant today as it ever was. Waterfall can be the perfect Project
Management framework, it lends itself well to hybrid approaches and if you have a smaller team or
your project is not prone to scope change it is probably the most effective process.
Like with actual waterfalls, if you get it right you have a lovely water feature that Ground Force’s
Charlie Dimmock would have been proud off; get it wrong and you can have a messy flood on your
hands. The more competent you are, the better the result you’ll get! As always, the Project
Management Service market is geared to help with any capability gaps that you have.

Straight Talk On Project Management



Chapter Five – The PMO



WISE WORDS

"A good plan can help with risk analyses but it will never guarantee the smooth running
of the project." ~ Bentley and Borman

"It's a bad plan that admits of no modification." ~ Publilius Syrus

“Estimating is what you do when you don't know.” ~ Sherman Kent

“The budget evolved from a management tool into an obstacle to management.”~ Charles
Edwards

As IT Projects evolve in complexity, you need something more RADICAL than

a RAID log


Think of the implementation phase of an IT Project.

Exciting, right?

All that pitching, planning and preparation has led to
this point! You are ready and raring to go and as you
line up the road ahead, your attention will have turned
to how you document and communicate within your
project. At this point, you are probably thinking about
initiating a RAID log. You can knock one up in Excel, one
of the most effective tools you can easily create for
your project ... until now ...
RAID logs are pretty cool!! RAID is mentioned in all
project methodologies, I can't think of a Project
Manager who doesn't use one.
However, I also can't think of a PM who doesn't also use other documents alongside it. Simplicity is
one of the advantages of the RAID log but it is also one of its drawbacks. Risk, Actions, Issues and
Dependencies are neatly covered by the RAID log, on one single document, but often project teams
find that they need other documents that review and record change, decisions, lessons learnt etc.

Your problems can really start when something happens in your project that doesn't fit into one of
these tabs - what then? This is where PMs either turn to a separate document or, worse still, try to
keep all this information in their head. The trouble is that with everything going on across your
portfolio, there's likely to be a lot going through that head of yours and, being human, PM's forget!
Truth is, what's not recorded well cannot be monitored, reviewed and acted upon.

Even when things are well recorded on separate documents, maintenance of these many documents
can be confusing for clients and stakeholders and it is often in this confusion that mistakes can occur
that leak value.

So often, a RAID log doesn't always give a full and accurate picture of the status of the IT Project.
Many Project Leaders and CIOs said that they needed something more RADICAL.

Appropriately, together with my colleagues at Stoneseed (the IT Project Management, Technical and
Service Delivery specialists), we streamlined the management of project related documentation into
one RADICAL log.

Let's break it down;

Stoneseed's RADICAL log covers;
R - Risks

A - Actions

D - Dependencies

I - Issues

C - Changes
A - Assumptions/Decisions

L - Lesson Learnt

The advantages are many, but chiefly;
1 - Having one document works better for the client ...

... and it works better for you. Rather than updating various documents, the RADICAL log gives you
real-time transparency. To have all project related info in the same place, a holistic overview
provides you with the opportunity for a regular look at everything! It is a living and breathing single
document rather than a hunt for information through loads of documents.

2 - Using one document means that events are MORE likely to actually get recorded
On this, a Project Manager friend compares RAID logs to when you put the bins out. He says. "We
have different bins for recycling paper, card, plastic, glass, garden waste, etc. The other night I had
some rubbish that I couldn't fit into one of these categories! I agonised for a few minutes and then
reluctantly threw it into the general bin. In many projects, this has been what has happened to, for
example, a valuable lesson that has been learnt. Where do you document that? It's not a risk or an
action, neither is it a dependency nor an issue and yet paradoxically, a lesson learnt could be all of
these! So, traditionally, lessons have ended up in the RAID log equivalent of our green bin and have
been missed by other project team members."

3 - You declutter each category
I was asked to help a project team with a floundering project last year. The first thing we did was
look through the recorded documentation for clues - from project charter to the delivery into service
plan, everything seemed meticulously prepared. Then, we looked at the RAID log and oh my days!!
Each category was pages and pages long giving a very unclear, instant picture of the health of the
project.

At RAID review meetings the team ran through the whole document starting with the risk section
which, from memory, was about seven pages. Now, many of the entries were not really risks - more
assumptions or concerns that fell into a bit of a RAID grey area. However, because of the RAID
methodology, there was nowhere else for the team to register these "grey area concerns" so they
had been lumped into 'risks'. The result was that when the team met on a weekly basis, they only
had time to chat through a couple of pages of the whole RAID log (all risk - i.e., stuff that might never
happen) and there was insufficient time for proper consideration of actions, issues and
dependencies - the real day to day life of the project.
Of course, better prioritisation would have helped. Even using a RAID log there were things this team
could have done better. Low-risk projects require that the team spend less time discussing risks
versus, for instance, issues, there was a failure in the implementation of this teams RAID log. That
said, filtering log entries further using the RADICAL approach means that only bona fide risks make it
onto that part of the spreadsheet because there is place elsewhere for grey area concerns.

4 – RADICAL improves response quality

The items in each of category of a RAID log necessitate different follow-up methods. The difference
between an "issue" and a "risk", for example. The former is a cast iron problem - it's something that
needs action, perhaps changes and there will be lessons that can and should be digested. A risk,
conversely, is a potential problem, effectively a problem that hasn't happened yet - it still needs
attention, solutions that may never be used must be brainstormed but in many cases, action is not
required. On a standard RAID log the results of these brainstorms can get lost at this point - where
do you log decisions for future reference if the risk becomes a reality? The RADICAL log provides a
natural place to register these decisions.

5 – RADICAL makes you think about the project as a whole.

The RAID log is a brilliant tool and it really focusses your mind on the things that you have entered
into those four categories. This can be a problem too. If you were told to notice how many vans,
buses, cars and lorries you saw on your commute into work, every time you saw a vehicle from this
category your subconscious mind would notice. You may arrive at work having not noticed all the
motorbikes, milk floats and tractors you passed.

Much of your project brilliance comes from when your primary attention is focussed elsewhere, that
is to say, that your eureka moments tend to come from your subconscious mind as opposed to when
you go looking for them. When you limit your main project log to the four categories of a RAID log
(and jot down other project events in separate documents) you train that part of your brain to limit
awareness and thinking to Risk, Actions, Issues and Dependencies.
Using a RADICAL log extends your project awareness and encompasses a more holistic set of
performance criteria.

Having one document, that is living and breathing, means you are always working on it and are,
therefore, always aware of what is going on - everywhere!!
In conclusion, it is appropriate that this new approach is called "RADICAL" - project teams using it for
the first time say this is exactly how the results feel. It's exciting! To return to my opening sentence,
where I invited you to imagine the implementation phase of an IT Project, exciting is exactly how it
should feel. Right?

IT Projects and business value – The importance of a strategic PMO



Business strategic alignment. This is a drum that I've
been banging for a long time. If the outcomes of your IT
projects do not translate into benefits for your business
- what's the point? Sounds so obvious but time after
time project management teams end up not working in
cohesion with their parent company's business strategy.
Last Summer I read a blog post by Moira Alexander, one
of CIO.com's most engaging contributors on Project
management issues, about the importance and value of
a strategic Project Management Office (PMO). I love
Moira's writing because she is so passionate about the
journey, we are all on and her thoughts often chime
with my own.
Moira wrote, "Strategic-level (PMOs), also known as enterprise project management offices, are
essential in developing, maintaining and communicating effective project, program and portfolio
practices. Having a solid company-wide strategic plan provides the blueprint that all PMO initiatives
should align with and be measured against. Unfortunately, only 41 per cent of strategic PMOs have a
high level of alignment with their organisation's strategy."

Considering the increased emphasis on the need for IT Projects to deliver greater business value and
the continuing high rates of project failure, it struck me as odd that less than half of organisations
had demonstrably aligned project and business outcomes. As I say, and my colleagues will confirm,
this is a well-banged drum of mine, so I decided to ask around to see how true that 41% figure
quoted was.

It turns out it's very true!

A quick straw poll of ten industry colleagues revealed five had experienced disconnect between IT
Project and overall business strategy in recent times.
I would urge you to read Moira's article as I think, as usual, she hits many a nail on the head!

Among Moira's tips, establishing a clear understanding of the company’s vision and mission may be
the most obvious but also the most important. As she writes, "Without a clear understanding of the
company's vision, mission and goals, it is virtually impossible to establish a successful PMO plan. To
get a complete picture of the company’s overall strategic vision and mission, PMO leaders must be
directly involved in executive planning sessions at a strategic level. This is the only way a PMO can
truly be effective in its approach and endeavours."

It's not a new thing. As far back as 2005, a study conducted by Dr Brian Hobbs with over 200
companies in the U.S. and Canada, found 39% of organisations had questioned the business value
brought by their PMO. "For the PMO to fill this new role," wrote the Project Management Institute
(PMI), "Considerable structural changes must take place in the organisation. The PMO has to evolve
from an operational structure of projects into a portfolio management structure which is focused on
the results and benefits generated by the project execution".

So, over a decade later why hasn't much changed?

Many report that it's a staffing issue.

As organisations increasingly place a greater focus on the business value of a Project Management
Office, they are naturally looking for talent with relevant experience. IT Recruitment Specialist,
Access Talent (our sister company) is reporting that IT job specifications are evolving to include
relevant skills, like requiring candidates to have a track record in business case focussed project
implementation, for instance.

The problem is that the IT Project Management Recruitment sector was already seeing a steady rise
in demand for PMO Specialists, fuelled by an influx of projects related to the recent changes to
GDPR, in a business world geared towards greater data compliance the PMO has stepped up to be a
crucial safeguarding resource. Most businesses have elevated their view of the Project Management
Office beyond that of a cost centre and PMOs are expected to create business value. With the
increased ROI expectation from project delivery, comes greater demand for the appropriate talent
to make that happen and the real possibility of a skills shortage in 2019.

Project Management as a Service (PMaaS) can help here, with resources to fill any skills gap that
may be threatening ROI.
Anecdotally, project teams also tell me that they are snowed under, as one Project Manager put it,
"We're too busy spinning all the other plates" to pay too much attention to business strategy
alignment. I'm not sure how much longer we'll able to use our workload as a justification for taking
our eye off the company objectives, it feels like the transport manager saying his drivers are too
busy delivering to pay attention to where they are delivering too. It cuts both ways though, while
project teams are often too busy to align their work with business case, I also know executive
stakeholders who are too busy running the business to have a firm handle on how IT Projects
contribute to it. This is a communication gap that needs bridging.

The PMI's learning library suggests five pointers that would assist with this goal communication
issue:
1 - Speak in proper language when communicating with business executives;

2 - Clarify projects' benefits to all stakeholders;

3 - Build a project plan that covers strategic risks;
4 - Guarantee the best use of company's resources;

5 - Understand how projects bring value to their company.
Again, it seems too simple but sometimes you just need the obvious spelling out.

I've seen end-to-end Project Management Office, sourced as a Service, deliver all the above. The
solution can be 'bought in' if your current structure is not delivering IT Projects married to business
case.

As always, in a blog, we only have time to skim the surface but if your projects are not delivering in
line with business need then, ultimately, you are wasting vital resources. It is crucial that your PMO
has a strategic plan and always executes accordingly - successful implementation of the plan being
the all-important bit in terms of delivering business value.

"Innovation results from creative ideas successfully implemented. Competitive advantage is as much
about execution as it is about strategy." This quote, from as far back as 2002, is as true today as it
was then. In 'Winning Through Innovation: A Practical Guide to Leading Organizational Change and
Renewal', Michael L. Tushman spelt out the challenges and many of them still exist today! The only
difference now is that the pendulum of responsibility has swung our way, Project Management
teams have to deliver in a way that is consistent with business strategy and if they can't businesses
may have to look for a project team that can.


Sources:

'Winning Through Innovation: A Practical Guide to Leading Organizational Change and
Renewal'(Tushman, 2002, p. 19).

https://www.cio.com/article/3288926/project-management/how-to-develop-a-pmo-strategic-
plan.html
http://www.pmnetwork-digital.com/pmnetwork/200608?pg=22#pg22

https://www.pmi.org/learning/library/strategic-pmo-align-strategy-enterprise-8124

The IT PMO type that delivers most value is ...



For a Project Management Office (PMO) to deliver peak
value it needs to be designed to support the unique
needs of its parent organisation and also to operate at a
level that the organisation can easily understand and
work with.

Even as I wrote the sentence above it felt such an
obvious thing to say but, time and again, I am seeing
the PMOs operate in harmony with the first half of the
statement and not the second. In other words, the
leaders of the PMO have identified that organisational
need must be prioritised to realise maximum business
benefit, but the way they go about it is at odds with
their organisation's culture, either that or they have
misunderstood the needs, or they are just speaking a different language.

Mbula Schoen, Senior Research Analyst at Gartner, says, "PPM leaders should engage the business
and key PMO stakeholders to identify the critical needs and issues of the organization, and then
design a PMO that will best meet those needs and resolve those issues."
Most organisations would be in broad agreement with all of this, business stakeholders and project
teams alike. After all, what is the point of any part of a business if it is not set up to deliver business
goals and function in accordance with the culture and the modus operandi of the business it is
serving. Often though, this is not the case and projects that should otherwise succeed are failing
through lack of alignment of working ideology.

The issue can be caused by a number of simple things. Projects teams can, paradoxically, be too
close and too far removed from their parent businesses to identify cohesion between each other’s
working ethos. Sometimes project teams are just too 'hard-wired' to adapt their way of working to
match their wider organisation and at other times they have become so closely aligned that they
forget standard project management best practice.

There are occasions where the maturity of the sponsor organisation has been misjudged. For
instance, some businesses need more than just a delivery into service function. They may need
business case analysis, perhaps risk assessment, they may need business alignment to be properly
measured and justified or they may need greater compliance. If the organisation's PMO is set up to
create structures that deliver project after project in roughly the same way, but the client needs
more then there will be a growing disconnect between the two over time.
Often though, it’s no one's fault it’s just that, well, things change!

Gartner's Mbula Schoen has identified four types of PMO that are commonly found. She categorises
them as "The Activist PMO", "The Delivery PMO", "The Compliance PMO" and "The Centralised
PMO". What is interesting is that, even with clear definitions alongside each one, it can be hard to
identify which approach best suits your current needs; let alone in the future. Given the speed of
change within business landscapes, what works now may not be suitable after disruption in your
market, or a takeover. While Miss Schoen is right to identify the four most common types, as I think

she points out herself, there is no "one size fits all" PMO and flexibility has, in my view, never been
more important.

The Project Management as a Service sector is perfectly geared up to help with all of this. If your
project management services partner has done the appropriate spade work, they will be able to
recommend solutions based on your maturity and unique business needs and if they have really got
to know your business and its requirements they will also be in a position to help forecast and satisfy
changing demands.
As previously mentioned, project teams can get too close to and be too distant from their
organisation, so often it is just really useful to have an independent pair of eyes look objectively at
the needs across your portfolio.
Last year, a project manager friend had to carry out a "Gedanken" or thought experiment for his
employer when the business was considering a takeover of a rival firm. The brief was to assess the
potential needs of the newly merged business and hypothesize about the type of PMO that would
be needed. He described the experience as being like "trying to get your head around Schrödinger's
cat"! Even with pretty robust forecasts, a good idea of how the new business would look and using
the same Gartner PMO models that we've discussed here; it was really difficult to map with any
degree of certainty the exact match between PMO type and business need.

Try it yourself! Spend a minute visualising where your business is at right now, think of your current
PMO, if you have one, or imagine what type of PMO would deliver the most value to your business
right now. Take a look at the four types identified by Gartner's Mbula Schoen below and try to throw
forward six months, a year, two years ... which of these will deliver most value then?

The Activist PMO? - "Popular in enterprises with distributed, business-centric project ownership, the
activist PMO takes a broad view and enabling approach as opposed to a controlling approach.
Typically, it has a view of incoming project demand, and supports decision makers by analysing
business cases for alignment and risk; that is, the PMO vets business cases and project proposals.
This broad view provides a project portfolio dashboard of the status of all projects that it maintains,
and oversight so that when projects in the dashboard go “red” - it might suggest or solicit remedies."

The Delivery PMO? - "Also known as the project delivery PMO — is perhaps the most commonly
found style. Gartner estimates that at least 40% of PMOs are mainly delivery PMOs charged with
planning and controlling the tactical execution of projects to business expectations. Project
managers are encouraged to manage their projects, proactively make decisions and escalate
problems. The goal is also to build repeatable processes and techniques that will work to build a
culture focused on results.
The Compliance PMO? - "Often the most suitable style for organizations where documentation,
processes, procedures and methodologies are lacking or inconsistent. In this scenario, the
compliance PMO tends to be tasked with establishing standard practices for measuring project
performance and the development of a capability for understanding the status of key initiatives."

The Centralised PMO? - "When PPM maturity levels are low, organizations depend on the skills and
abilities of key performers to get work done. At higher levels, efficiency is key, and management
seeks to reduce this dependency and establish reliable processes for project tracking and reporting.
A centralized PMO is therefore formed as a place where new hires can be quickly brought up to
speed on how best to get project work done in the organization. In the centralized PMO,

representatives from the various project support organizations get together to share their practices
in a best-practices council."

Has your mind turned to blancmange yet?

To conclude. While it is true that you can identify which types of PMO deliver the most value NOW,
based on past data, it is a lot harder to predict how to align a visualised future PMO with the needs
of your future business. My friend said it was like "minding mice at a crossroads!"

Where's that Schrödinger's cat when you need it!!
The most sensible solution appears to be the one that will give you the most flexibility. Once he'd
got over his cat and mouse issues my friend's conclusion to his boss was to recommend use the
Project Management as a Service market to give the business access to resources and ways of
working as and when they were needed - "why build when you can rent" was his closing statement
to the board. The takeover is yet to happen, which is why I can't name the business (or my friend)
but if in the near future you hear of a large corporate takeover and you marvel at the apparent ease
of IT integration and the versatility of the IT project management, you'll know that you heard it here
first.

The same flexibility could be the key to your PMO delivering more business value to you too, now
and in the future.



Source:
https://www.gartner.com/smarterwithgartner/4-types-of-project-management-offices-that-
deliver-value/

Straight Talk On Project Management



Chapter Six – IR35



COMMENTS

“We appreciate the desire amongst the professional contracting community for clarity regarding
IR35,” ~ Association of Professional Staffing Companies’ (APSCo) Chief Executive, Ann Swain.

“As we face uncertain times, neither increased cost nor decreased flexibility are helpful to
employers,” ~ Chief Executive of The Freelancer & Contractors Services Association, Julia
Kermode

“I understand the professional contracting community has concerns about the ability and
willingness of HMRC to make substantial improvements in the way it administers IR35,” “but I
know that HMRC is committed to a complete overhaul of the way IR35 is administered to address
these concerns.” ~ Exchequer Secretary, David Gauke.

IR35 and Private Sector IT. You Are Here!



The Private Sector IR35 countdown clock is ticking
louder and louder. Before you can say "non-compliant
off-payroll Project Manager", it will be time for private
firms to follow the Public Sector pioneers into this new
world.

It's come around quick, hasn't it? One of my accountant
friends drily commented the other day, "It doesn't seem
like two minutes since we took down the IR35
decorations!"
The use of contractors in IT Project Management has
greatly increased over recent years. With good reason,
many businesses see contractors as a way to quickly
hire the specialist IT skills that they need, without
having to commit to a permanent hire. It can be justifiably argued, that operating in this way has
given businesses greater agility to respond to the market needs of the present, and innovate to meet
the market needs of the future.
This has not escaped the attention of the HMRC though.

After, in the view of the taxman, a highly effective rinse of the practice in the Public Sector, eyes
turned to the Private Sector where the cost of a disguised employment to the treasury was
projected to increase from £700 million in 2017/18 to £1.2 billion in 2022/23.

Which is how we find ourselves where we are - however many days, weeks or months away form
IR35 day we are when you read this.
Those three words are key - "where we are".

I think acknowledging where you are is the most important thing that you can do right now.

I have spoken with employers who are 100% ready and I have spoken with those are 100% not. I
have talked with those that know they have to do something and those that have buried their head
in the sand. Some have a clear road map; others have a roughly sketched plan. Some could go on
Mastermind and answer questions on IR35 as their "Specialist Chosen Subject" and at the opposite
end of the scale we have heard one "what's IR35?"

It is a very broad spectrum. Everyone is on their own journey (and working at their own pace), but
the inevitability is that we must all arrive together. The important bit is accepting where you are on
the map and then taking the next step.
You'll have seen those maps at the shopping mall or the theme park or the zoo. There's always this
huge, confusing expanse of stores, rides or animals and a very big arrow with a very simple message
- YOU ARE HERE. If you want to get to the handbag shop, the big dipper or the elephants, knowing
where you are in relation to them is key to planning your journey. So, it is with IR35, knowing and
accepting where you are is vital to plotting your journey to April 2020.

Knowing where you are, allows you to calmly assess your options. Do you bring your contractors in-
house and add them to your payroll? Do you absorb costs associated with IR35, or have an awkward
conversation with your clients? Or do you completely re-frame your thinking on project resourcing
and consider way to eliminate 'disguised' employment altogether, resourcing through Stoneseed's
Project Management as a Service (PMaaS), for example, where our people are on our payroll and
where IR35 is essentially de-scoped.

I'm writing this in April 2019, but you could be reading it in July, December or even closer to the
deadline in 2020! And it almost doesn't matter - as long as you accept that YOU ARE HERE and work
from there.

We have put together a calendar which will help you with resource planning for IR35. This is based
on our experience helping organisations transition their resourcing models and feedback received by
both Stoneseed and our sister company, Access Talent (the IT Project Management Recruitment
Specialists). You can find the calendar here - www.stoneseed.co.uk/ir35























Summer 2019 will be remembered, as much for the heatwaves, barbecues and paddling pools as for
gauging current work forces, resourcing chains and tax liabilities. By the end of July 2019, I'd say that
you need to have a robust understanding of your current work force, crucial contract roles and also
have a strong sense for how rate increases may affect you. You should have started planning new
processes or investigated alternative resourcing channels like PMaaS, where IR35 becomes
irrelevant. Summer would be a good time to have started stakeholder conversations too, so that
there are no unexpected surprises.

By November, hopefully, the only fireworks will be the ones marking Guy Fawkes night as you advise
contractors of your plans. Remember, that this is a worrying time for contractors whose livelihoods
are potentially about to change. Prevent undue worry by engaging and informing your workforce
throughout.
By Christmas and New Year, reflections on "another year over and a new one just begun" should be
complemented with reflections on your current contractual arrangements and amending them to
fall in line with April's changes.
The first quarter of 2020 should then be a time to prepare to hit the ground running: training your
people on any new processes, engaging stakeholders, assessing new job roles and adverts for
compliance.

Then, my favourite: by April 2020, you should have a bottle of champagne in the fridge ready to
toast all your hard work and your organisation's compliance.

Glancing at these, you may feel your heartbeat start to race and your blood pressure begin to rise.
What if you're late? Don't panic! We've been through this with the Public Sector and we are here to
help your business, wherever you are in the journey. You Are Not Late.

One of the most common lines we hear from clients is "we are so late" and, looking at the calendar,
this may be your reaction too.

In truth, you're not late. You are where you are!

Remember those three words: YOU ARE HERE!
It's the quality of your response to this that will matter in April 2020.

I had this exact "we are late" argument with a HR Director friend who said that having embarked on
a compliance mission after the Public Sector changes, his firm was now six months late. Then two
months passed, not much progress was made, and he told me they were now eight months late. It
took me a further month of telling him "You are here" for him to accept this and take positive action
- (thank goodness, otherwise by this point he'd have been nine months late!!!)

The point of this is that you will be late if you are not compliant by IR35 day, until then YOU ARE
HERE.

So, accepting that, what's your next step?



IR35. What next for IT? Private Sector pain?




(At the time of writing – January 2018) If you have had
anything to do with Public Sector IT procurement over
the past two years or so, either as a client or a
contractor, IR35 has probably never been far from your
mind.
My friend, a Public Sector IT Project Manager, jokes that
he'd started seeing IR35 everywhere, "It's been the
topic of water cooler conversations, seminars,
newsfeeds. I had to laugh, even on holiday a cocktail
bar, Bar 35, had replaced 'ES' with '35', you know, like
you do with passwords ... so Espressotini became
35PRESSOTINI. This was cute until I perused the menu
some more and saw 'VIR35CENCE', 'FIR35TONE' and
'SAPHIR35'!”

That does sound quite TIR35OME!
The fact is that IR35 ‘off payroll” legislation shook up Public Sector IT service procurement.

We said it would.
We also said that client organisations and contractors alike had to act to be prepared for the April
2017 implementation. Some did, some didn't. As a result, some suffered greater pain than others.

There has been something of a collective sigh of relief from many in the IT sector over fears that the
government would extend the new IR35 ‘off payroll’ rules ... but those sighs may be short-lived.

Although it was not explicitly outlined in the last Budget speech, other documents released on the
same day mentioned the possible extension of the rules for personal service companies in the Public
Sector to workers in the Private Sector. I believe that the government has effectively shown its hand,
and will consult in 2018 on how to tackle ‘non-compliance’ with the intermediaries’ legislation in the
Private Sector.

Our own businesses give us a unique vantage point from which to observe and comment.
Stoneseed provides Project resources into both the Public Sector (where the new rules apply) and
the Private Sector (where they don’t). Also, while we favour the use of our own employed resource
(where IR35 becomes irrelevant), we also work with a number of Personal Service Companies
(where it is highly relevant).

Stoneseed's sister company, IT recruitment specialist Access Talent, is in regular contact with many
influential IT HR leaders who are feeding a constant sense of the mood music of the industry. It
allows us to speculate with some confidence and authority on what will happen further down the
line.

To get a sense of what the Private Sector can expect, let's leverage hindsight to give us some
foresight and reflect on the impact of IR35 on the Public Sector.

Recent research by APSCo found that the Public Sector is suffering the consequences of the new
IR35 rules, with almost three-quarters of recruiters (70%) finding contract placements in the sector
have dropped since April 2017. Almost half (45%) report increasing charge rates for contractors. On
the face of it, that’s a dramatic change but the truth is, we don’t really know yet what the real fall in
resourcing looks like yet. We suspect that the impact on the Public Sector, whilst significant, was not
quite the predicted apocalypse.

A number of factors have effectively softened the blow, and there may be key lessons here for the
Private Sector.

1 - Some Public Sector organisations have planned ahead very effectively, and turned to alternative
resource models. They may have increased internal staff headcount, or accessed talent through the
"as a Service" markets with partners who can provide employed (ie. PAYE) staff. The thing is - they
did something - they acted positively - and it worked.

2 - Many PSCs have understandably taken the view that the new rules have swung the pendulum too
far the other way, and now they have the worst of both worlds. They are taxed as an employee but
without the benefits and the employment rights. However, for some (and this depends very much
on circumstance) the tax maths have not been quite so dramatic. The restructure of tax rules on
dividends have meant that the increase in their tax burden is not as significant as it once was. They
have absorbed the cost and moved their contract to Umbrella Terms.

3 - Some have renegotiated terms. They have adopted variations on the above themes and brokered
compromise arrangements, such as a slight increase on day rates to compensate for the increased
tax burden.

4 - Many PSCs with a highly prized skill set have increased their rates significantly, keeping their take-
home pay at the same level – ironically the Public Sector have footed the bill for these increases.
5 - Many have taken the IR35 Test and adapted. They have used HMRC's online tool to effectively
take themselves out of the scope of the new rules, naming substitute workers, working to a clear
Statement of work with defined deliverables etc.
6 - Many contractors took themselves out of the equation altogether by moving their skills to the
Private Sector.

For many, this is a case of balancing risk. We don’t really know, at this stage, how aggressively HMRC
are going to challenge PSCs, but certainly, given the requirement for intermediaries to report back to
HMRC on off-payroll workers, they now have the information at their fingertips.

So some lessons, but the burning question for many is – will the rules be extended to the Private
Sector?

This is what they've said, “The government will carefully consult on how to tackle non-compliance in
the Private Sector, drawing on the experience of the Public Sector reforms, including through
external research already commissioned by the government and due to be published in 2018 ... a
possible next step would be to extend the reforms to the Private Sector, to ensure individuals who
effectively work as employees are taxed as employees even if they choose to structure their work
through a company.”

It's a pretty clear statement of intent, isn't it.

I think the question is probably easier to answer in reverse ... Why wouldn’t they extend it to the
Private Sector?

One thing I have learnt about tax is that, although it can be incredibly complicated, it is (in the main)
pretty logical.

I fail to see any logic in applying one rule in the Public Sector, and then not applying it to the Private
Sector. The new rules have worked ... kind of ... or at least they haven’t failed!

Look at this from HMRC’s perspective if you can. The general direction of travel for tax for the last 4
years is to tax employees less and company shareholders more, I appreciate I may have
oversimplified things here, but take a look at some simple facts. Over the last four years, the
government has ...
1 - Increased basic and higher rate tax bands (unless you work in Scotland!) thereby reducing the
amount of tax paid on PAYE income.

2 - Effectively taken away the tax-free basic rate band on dividends (replacing with a £5k allowance),
the preferred mechanism for most Company Shareholders to reduce their tax burden, whilst still
paying Corporation tax on company profit.

3 - Effectively narrowed the tax gap between contract and permanent workers. Contractors will
often still pay less tax, but there is now at least a debate to be had once you throw in some of the
benefits of sickness pay, paid holiday, pension etc.

By extending the legislation to Private Sector workers the government could fast-track this process,
and potentially (some would argue) level the playing field. Furthermore and, as alluded to earlier, by
introducing it into the Public Sector there has undoubtedly been a leaking of skills into the Private
Sector. Why wouldn’t HMRC seek to plug this leak?
It’s quite clear what this means for the Personal Services Companies, but what does it mean for the
engaging clients?

Well disruption, for one thing, an increase in day rates and undoubtedly a need to review current
resourcing models.
This could be only 15 months away.

Let that sink in.
You could have just five business quarters to prepare.

How quickly does that time go?!

If we are to learn anything from the Public Sector experience it should be that now is the time to
start preparing. Begin looking at your Project Portfolios for 2019, and how these will be resourced.
Will you be ready for a hike in costs ...?

... or are there other delivery models that might provide the answer?

IR35 – How to avoid Public Sector IT talent shortages




Guest Blog by Jamie Buttle (Stoneseed’s Managing
Director)
(At the time of writing – March 2017) When the
Government announced changes to IR35 and off-payroll
working rules for public sector workers like IT
contractors, a wave of confusion rippled through online
forums used by contractors and hirers alike. There are
some great online resources that explain the changes,
not least the one published by Stoneseed, in this post
we'll explore ways to protect your organisation from
the changes to IR35 and the potential implications that
they may have on your IT operation.

Firstly, a brief catch up.

IR35, also known as the Intermediaries legislation, was a response to perceived ‘tax avoidance’ by
contractors operating as Personal Service Companies (PSC) but fundamentally behaving like
employees - what became known as "disguised employment". Clearly many contractors deliver
services to clients that could not be construed as disguised employment and so there needed to be a
test to define which talent fell into which category and guidance on who was responsible for making
the call.

From April 2017 there will be a significant shift in responsibilities and liabilities. Simply put,
responsibility to determine a public sector contractor’s IR35 status shifts from them to you, the end-
client.

The government acknowledges that there will be "a significant initial impact" but seem to consider
that this will be mainly confined to extra admin duties for public sector organisations. However,
many public sector hirers are also raising fears that contractors will either increase their prices to
mitigate any extra tax due or that they may shift their talents to the private sector, in which case the
hiring body could face higher costs and may struggle to recruit the best talent.
According to a survey by the Recruitment and Employment Confederation (REC), few public sector
hirers are in favour of the changes with almost seven out of ten HR managers (69.5%) fearing a
negative impact in terms of increased wage bills, their ability to attract talented individuals and their
ability to afford the experienced contractors required.
Furthermore, the Association of Chartered Certified Accountants (ACCA) warned off a “significant
risk” as public sector organisations are likely to mitigate the potential risk of liability by using only
large outsourcing service providers, again with cost implications for the sector.
Most commentators and observers agree that implications will reach further than extra paperwork,
to what extent will depend largely upon how ready for the change organisations are. There are a
number of things that you can do now to protect yourself.
1 - Start the conversation NOW.

Organisations that are dependent upon contractors should have started the dialogue with their
talent already and if that’s you and you haven't - start now. To be clear, the client needs to take the
view on whether a particular service provided falls inside or outside IR35. In the interests of fairness
to all, this is a judgement that is better made in a calm, measured fashion before the rules changes
rather than in a rushed panic afterwards.

Having made your judgements, you will then have time to react to any decisions made by
contractors on how they will operate moving forward, i.e. if they stop providing their services to the
sector you will have some space to seek an alternative.

2 - Consider the Project Management as a Service market.

This is probably the cleanest way to mitigate risks. Although it is true that booking contractors
through agencies might shift liability to the intermediary, the IR35 decision will rest with the public
sector organisation as opposed to the agency and as buyers realise this they are increasingly looking
to G-Cloud for inspiration.
All public sector organisations can use the G-Cloud or the Digital Marketplace to find people, services
and technology for IT projects. The Project Management as a Service (PMaaS) market offers you a
complete range of Project Management services, including full Programme Management Office
(PMO) providing assessments, governance, tools and people to improve your delivery capability and
performance. Best of all, engaging services this way is unlikely to be perceived as "disguised
employment".

Early adopters are also benefitting from consistently high-quality IT Project Delivery, often with no
net increase in the overall portfolio costs and are grateful to the IR35 changes for practically forcing
upon them the opportunity to rethink their approach to IT.

3 - Be proactive and seek win/win arrangements with contractors to keep them outside IR35
In some cases, IT contractor arrangements can be defined to ensure that they do fall outside IR35. If
you currently arrange substitute talent when your contractor is ill, for instance, this would ‘fail’ the
IR35 test and be deemed as "disguised employment" but shifting this responsibility to your
contractor might rebalance the judgement. Again, accessing talent through a legitimate Project
Management as a Service arrangement would be the clearest way forward.

It is recommended that public sector hirers and contractors work through HMRC's IR35 criteria
together to find work around solutions that work for both client and contractor but ultimately, more
importantly, the tax man! An independent review may be the best way to ensure compliance.

In conclusion, time is running out and for public sector bodies doing nothing is not an option. Many
IT contractors that I talk with are already considering their future outside the public sector. It is vital
that you do everything that can to keep them outside IR35 or convince them of the benefits of
coming "on payroll" with you (good luck with that) or you risk losing key contractors and the crucial
strategic skills they offer. Many public sector organisations are skipping this step altogether by
reimagining their approach to IT services and project delivery procurement, furthermore, having
entered the ‘as a Service’ market many are wondering why they didn't do it sooner.

Source:

https://www.cloud9umbrella.com/public-sector-left-frustrated-proposed-government-changes-ir35

READ MORE BLOGS FROM STONESEED



Stoneseed publishes blogs on a regular weekly basis, which you can receive directly to your inbox
by email subscription. We focus on Project and Programme Management topics, Project
Management Office, Governance and Methodologies and practical advice.

Subscribe at stoneseed.co.uk


COPYRIGHT NOTICE
© www.stoneseed.co.uk 2019 All rights reserved.

Unauthorised use of this material, reprint, reproduction or translation of any part of this work
without permission of the author or Stoneseed Ltd is strictly prohibited.