How does it all work?
Communication and Project Management are two
extremely and increasingly important terms in the IT
space. Communication in IT is enormously important. IT
people need to be able to explain the most complex
issues to management teams in a common language, and as
business sizes increase and application the issues
become more abstract, this is becoming progressively
more difficult.
It is common nowadays for a developer to work in one
area of development if they're in enterprise. Be
that user interface design, user experience, database
management, or server-side scripting it is usually done
by a specific person who specialises in that area.
There are various reasons for this, many of which are
valid and primarily oscillate around the idea that a
person will come to have a strong understanding of
their area and will therefore be able to solve problems
more quickly.
This looks great at the moment, a group of people
who are all experts in their area working on their own
parts of the project in an efficient manner. Tasks are
delegated by management to each member as required and
those tasks are completed within the service level
agreement, and all is well. After about a while a few
major enhancements are requested, and a group of fresh
hires arrive to help out. Your small team has now
grown, and there are three to five people specialising
in each area. New areas have spawned, you now have a
dedicated security team who seem to be slowing
everything down, you have a WCAG compliance team making
your site ugly and slow, and you have a rock star UX
team who are making everything 'material
design' or something equally ridiculous.
Everything is starting to turn into a bit of a mess,
so they assign each area their own manager. These
managers don't directly contribute to the technical
work load; their job is to communicate with the other
managers about the workload and the overall goal. Then
they all start fighting because the UX guy uploaded a
script without giving it to the security team, but UX
guy said it was irrelevant because it was purely user
experience based.
So they hire a project manager. Somebody to absorb
the arguments and repair the damage caused. The project
manager builds a workflow system to make sure issues
like this don't happen again. So now every time
someone codes something, before they can upload it to
the repository they have to sign off a bunch of
checklist items; like have they put it past security,
they have to get it checked off by WCAG for compliance,
they have to put it past their one-up for quality
assurance.
Whilst this has resolved many internal disputes and
is resulting in higher quality product, it has also
greatly slowed down production. To try and alleviate
this, each developer in each of the teams is given
their own team of developers to train and work with
them. They are now team leaders with a team of junior
developers working alongside them. Suddenly the project
manager is now in charge of five times as many people
and can't cope, so they get each development team
their own section manager to report to the project
manager. Like the team leaders and managers, the
section leaders are responsible for communicating with
the group above and below themselves. Our diagram now
looks like this. Don't forget each area also needs
an architect to decide the best way for them to go
because the section leader can't think in the big
picture way. Which means with the project manager sits
a solution architect who gets paid so much to draw
clever diagrams and think about the future it would
make you explode.
This level of abstraction is where much of
enterprise is today. If a junior developer spots a
problem, he needs to tell him team leader, who needs to
tell the section leader who needs to tell the project
manager who needs to get stakeholder input and decide
on a solution, put that solution past the architects to
make sure it's in alignment with our goals, report
back to the section leaders who then communicate with
the team leaders who let the developer know what to do.
Except they don't tell him what data to store in
his audit trail database like he wanted, they tell him
the company has decided to move onto the cloud or
something equally useless.
Imagine what this could look like in another ten or
fifteen years. The rate of change is only increasing.
At this stage even adding a text box to a website is an
awkward ordeal, let alone a complex feature addition or
data migration. The rate of abstraction is out of
control and it's only going to speed up until a
new, less hierarchical ideology comes along. The only
glue holding everything together is communication.
So how do I communicate effectively?
This has been gone over countless times by countless
different people. Traditionally, I have stuck to
Aristotle's mantra to tell them what you're
going to tell them, tell them, and then tell them what
you told them; but recently this has started to lose
its impact. It's easy to ponder the reasons for
this loss of impact, be it mobile phones, fast
internet, the bright colours in movies, fast food;
people have shorter attention spans and we as
communicators need to cater for that.
A listener has a choice when they're listening
to a presentation or speech, and this is pertinent even
in a meeting or conversation. They have the choice to
not listen. This choice is made easier for them if
you're boring or badly presented, but it's also
pretty easy to not listen if the listener decides that
what you're talking about isn't applicable to
them. If you tell people what you're going to tell
them, they can easily decide they don't care and
jump straight onto their phones.
Time today is very valuable, and people are very
quick to dismiss somebody on this basis. When an
audience is awaiting your presentation, they don't
want to know what they're going to hear, they want
to know why they're there. So we should open our
presentations not with an agenda, but with a framing
idea that will answer the question of why the audience
should listen.
Once you have answered the question of why, you are
to start with the main content. Sometimes this part is
difficult, but if you have ever spoken to anybody high
up the food chain in business or government you're
going to know you need to be concise or few will give
you their time. The common urge when you're
speaking about your speciality is to tell the audience
everything you know like in a University lecture, but
you're at work now and things are different. Keep
it concise and only present ideas that are vital to
your contention.
Conclude in a similar manner to your opening,
finishing with a salient idea that reminds people why
they have attended and what they have gained from
it.
What about in the DSS?
As in any workplace there is an array of ways we
communicate. These include informal talks, email,
formal meetings, IM, phone calls and many others. There
are often more layers inside these methods, such as
inside formal meetings there are general meetings,
section meetings, branch meetings, group meetings, team
meetings, scrums and surely a lot more. There are a few
unwritten rules that are generally followed within
particularly the higher-level meetings, such as
attempting to always speak in a professional capacity
rather than a personal capacity. This is directly in
alignment with the ACS values, particularly that of
impartiality. Make sure when you speak people know who
you are and what authority you have to comment; make
sure you speak with political sensitivity and don't
speak negatively of somebody or a group without first
talking with them.
What about formal documentation?
DSS has several communication policies in place.
These include several about sponsorship, media
engagement and merchandising which are largely unneeded
in my area of work. There is also a Stakeholder
Engagement Policy that we have been following in the
process of the ICTGP. This document is a key document
written to implement the DSS Stakeholder Engagement
Strategy, which is designed to ensure that we are
effective, efficient and, perhaps most importantly,
consistent in the way we engage with our stakeholders.
This formal documentation has enforced changes in
myself as a project manager, as I now have scheduled
meetings with stakeholders and formal documentation to
write up for these meetings, even if they're only 5-10
minutes in duration. Without this documentation I would
have just met up each time we hit a milestone or
roadblock -- however through documentation I have
learned that this isn't the desired way.
Our project has a meeting etiquette policy which
outlines communications and behaviour. Our meeting
minutes have consolidated action items that list who
needs to do what, when. Items that have not been
completed by their due date are highlighted and
assistance is offered to the resource who is supposed
to be doing them. Whilst this is not written in policy,
these are the actions that have been taken for the
first 6 months of the project, and as they're working
the behaviour will continue.
What have you witnessed?
Once a meeting has commenced, DSS employees largely
obey all of these rules. There may be the occasional
quip depending on the level of formality, but usually
everything is followed. With the exception of one thing
-- punctuality. There is a dangerous understanding that
people can just rock up late and it's all fine. We had
a joint-section meeting (about 100 people) scheduled
for a specific time in the morning. Myself and my team
arrived 10 minutes early as is appropriate. The chairs
of the meeting arrived ten minutes late, and then spent
about 15 minutes trying to get the projector to work.
All I could think was you're literally in front of a
room with tens of millions of dollars worth of IT
professionals, developers, designers, architects;
everything you can think of, and you think it's ok to
make a mockery out of all of us. And then the to
nobody's surprise the meeting went way overtime. A few
people quietly walked out early, but the contents of
the meeting was extremely important so some people
couldn't.
Punctuality is something that needs to be worked on
in the DSS. We can argue that it's derived from the
work-life-balance focus of the department, the apparent
perceived laziness of APS people; but for the point of
this writing piece that is irrelevant. I will make it
my goal to never be late to a meeting without setting
expectations reasonably in advance.
What has education changed about your
behaviour?
My day to day work life has no project management
involvement. DSS uses Prince2, and as the project
manager of our graduate team I suspect I am doing what
any developer/inexperienced project manager would do in
this situation. I'm doing a bastardised version of
Prince2 mixed with Agile. How do you make Prince2
agile?
Like this apparently. Whilst my formal education in
project management is miniscule (read: one undergrad
unit), this book (as well as
this one) gave me the powers I need to probably
succeed. Before I started reading Prince2 Agile all I
was thinking was "Prince2 literally means projects in a
controlled environment, Agile is catering for
somewhat the opposite of that. However it suits our
project perfectly because it is a Prince2 foundation
that caters for ongoing change, and because we
immediately identified scope creep as a massive risk
for our project it's important to tailor appropriately.
I'm not ready to jump into scholarly literature in this
rea as I don't yet fully understand the foundations.
However I have been going through these books as the
project goes on and they have given me the ability to
decide an appropriate set of deliverables that we can
produce in order to create a high quality final
deliverable.