Improving the Productivity
of an IT Organization
Paul Hookham is a highly experienced
and successful IT delivery executive
with an outstanding track record
working for some of the world’s most
demanding customers.
He is passionate about quality and
believes that people do their greatest
work in an empowered, blame-free,
supportive, and learning environment.
He is comfortable working in
software development, application
support, or infrastructure delivery
and is an evangelist for continuous
improvement.
Paul is also a master practitioner of
neurolinguistic programming (NLP), an
NLP master coach, a published author,
and an experienced speaker.
He can be contacted at
paul@exceedus.co.uk.
© Business Expert Press 978-1-94819-850-9 (2018)
www.businessexpertpress.com
Paul Hookham
Abstract: When I ask the question “What is meant by
productivity improvement?” the standard response is
­
around getting “stuff” out of the door quicker than the
competition. Often, an image of people rushing around
like headless chickens springs to mind. This does not
­apply to technology functions and probably not ­anywhere
else either. This article explores a n
­ umber of ways that
productivity can be improved, drawing from the author’s
coalface experience. They are not i­mmediately obvious.
Keywords: Constraints, DevOps, Flow, Lean, Mean
time to repair, Metrics, Minimum viable product,
Monitoring, Process improvement, Time to market,
Value stream, Work in progress
Introduction
For as long as I can remember, executives have
­retained a laser focus on productivity. This is perfectly
understandable. They need to understand what their
­
bang per buck is in order to satisfy their stakeholders
and, if applicable, their shareholders, that their ­company
is moving in the right direction.
Sadly, I have witnessed very few instances where the
data they are presented with actually means anything.
The graphics and balanced scorecards may be visually
pleasing but not much else.
For me, productivity is not just about efficiency—
whether it be an individual, a team, or an organization.
Significantly more important is the effectiveness of the
work being done. Is everybody working on the right
things? Are we delivering real value to our customers?
Are we delivering what they need as opposed to what
they want (these may be one and the same thing, of
course).
Expert Insights
1
 Improving the Productivity of an IT Organization
This is the area that is often ignored. One
could then argue that there is good and
bad productivity. It is pointless to simply
speed up delivery as all that will happen is
that the wrong thing will be delivered a lot
faster—not much help!
Quality is another area that cannot be
­ignored as even if your organization is both
efficient and effective, it won’t be thanked
if the delivered product is riddled with
defects.
For the purposes of clarity, the d­ efinition
of productivity as it is used in this article
comprises effectiveness, efficiency, and
quality.
If one of these components is missing,
then the organization runs the risk of not
satisfying its customers, and with such
fierce competition around, they may well
vote with their feet and move to a d ­ ifferent
supplier who can demonstrate better,
cheaper, and faster and not just faster.
IT Productivity Insights
Let’s start with a war story on how I’ve
seen IT productivity measured in the past.
The same thing happened at two major UK
­corporations, arguably leaders in their field
and well established in the top 100 leading
shares (FTSE-100).
I will leave it to you to decide whether
the experience was good, bad, or ­indifferent,
but there may be an element of leading the
witness, although I don’t think I’ll have to.
You will not be surprised to learn that
a large consulting firm led the charge.
It would have been unthinkable to even
­consider for a minute that the IT teams
themselves would know where to start,
wouldn’t it?
To give credit where credit is due, the IT
management team in both ­companies stood
up in front of everybody and e ­xplained
why it was felt necessary to complete the
exercise and what would be done with the
results. There would be no secret meetings,
and the development processes were b ­ eing
measured and not the people. This was
a critical piece of communication to stop
2 © Business Expert Press 978-1-94819-850-9 (2018)
www.businessexpertpress.com
tongues wagging about redundancies, and
it seemed to satisfy the assembled masses,
at least initially.
But then—the process started and it all
changed.
It turned out to be a bureaucratic night-
mare, involving a huge amount of form
filling, number crunching, and ­searching
back through old change requests and
­defect reports. Twenty-page questionnaires
had to be completed and handed over to
an external consultant (and I use the term
“consultant” loosely).
What should have taken a few days
ended up taking a month, and this
­included w ­ orking evenings and ­weekends
to m ­ aintain delivery commitments. It
would not have gone down well with the
­customers if they were told that their next
release was being delayed because the
teams were counting lines of code and
­filling out forms instead.
After what seemed like an age,
the  ­ exercise was completed, all forms
were s­ ubmitted and then keyed into some
top-secret a­pplication by the c­onsultants
­
(notice they have become ­plural). A ­findings
report was automatically ­ produced and
presented to the organizational grown-ups
behind closed doors. It took a while before
anybody got to see any white smoke.
The executives did keep to their word
and presented the outcome, which
­included a comparative study of where
each part of the organization stood against
their ­competitors in the sector. In one
­organization, ­production support turned
out to be the most productive—which is
quite an achievement for an area that
doesn’t write any code. To this day, I am
not sure what happened there.
The productivity measure was based
on the average number of uncommented
lines of code that were produced by the
­organization over a 12-month period. It’s
not the sort of thing that is easy to bring
into any conversation, nor is it easy to
­defend among a peer group who actually
understand what the outcome is telling
Expert Insights
 Improving the Productivity of an IT Organization
them. Who wants to know, and what on
earth could you possibly do with the data?
Needless to say, the natives became even
more restless. They could see no b ­ enefit
from their labors.
What did it matter if Company X ­produced
more lines of code than ­Company Y? Does
this make it more ­efficient? Aren’t apples
being compared with bananas? Should
Company Y be penalized for producing
less code? What if their code was more
efficient?
In the end, absolutely nothing was done
with the recommendations, and the whole
process fell into disrepute. I’m certain the
consultancy firm will be re-engaged in the
future to help with things they are good at,
but in my experience, benchmarking isn’t
one of them.
My story ends with an apology, as I did
say I would leave it to the reader to d ­ ecide
whether the experience was good, bad, or in-
different. My view is that it was ­unproductive,
measured the wrong thing, and caused many
initiatives to lose m­ omentum. However, it
did become the subject of much amusement
in the local bars and restaurants. In fact,
morale improved—there’s always a positive,
isn’t there?
The moral of the story is that one cannot
judge the productivity of an IT o ­ rganization
on the basis of the number of lines of code
it produces, controversial as this may seem.
It’s only a short step away from ­ putting
photographs of lions on the office walls and
informing your people that “the customer
is king.”
Having cleared away the dishes from the
starter course, it’s now time for the entrée.
How can productivity be improved?
How do you know if it’s improving? What
impact is it having on the bottom line?
I do not believe that IT can be solely
responsible for improving productivity. It
can’t do it on its own.
That may sound a little strange, but it
will need every area involved in the flow
of work to play its part. The silos that exist
in many organizations need to be flattened,
© Business Expert Press 978-1-94819-850-9 (2018)
www.businessexpertpress.com
and everybody needs to work in multiskilled
autonomous teams in order to achieve the
organizational goals. This i­ ncludes not
only the technical areas such as software
­development, application ­support, quality
assurance, and testing but also security and
the business product owners themselves.
One of the first things to analyze is the
way the work flows through the system;
from business idea generation through
to the realization of the benefits in the
­production environment. This is the value
stream and can be any end-to-end process
such as opening an account or setting up
a pension; anything of real business value.
It is an eye-opening exercise to take a
paddle upstream, walking together as a
multifunctional team. It gets everybody
on board in their understanding of how
the work gets done. Some key people will
be met  along the way, so questions can
be asked about their issues in the way
the work works. It will highlight where
the b ­ ottlenecks are, and for the first time,
­everybody will begin to see the big picture
and not just their piece of the action.
At the end of the walk (it may be
­necessary to do it more than once), it will
be possible to draw a map that highlights
all the work in progress along with the time
it takes to get from one stage to the next.
Where are the delays?
Where are the dependencies and handoffs?
Why are they happening?
How does the work actually work?
What action needs to be taken to remove
the constraints?
A number of reasons will be identified,
which could include some of the following:
■■ Vastly elongated wait times at various
points in the stream
■■ Late engagement by key functions such
as security and support
■■ Overreliance on a limited number of
subject-matter experts who have become
single points of failure
Expert Insights
3