Project Management
Defining bad project managers is easy, they are the ones
that ask you how their project is going cause they don’t know and/or don’t care,
or ask you if they should turn up to their own project meetings. Disengaged,
disorganised, no milestones, no updates, no idea of issues and risks, no chance
of success. Go too far the other way and you can have a micro managerial
fanatic bogged down in detail and making no progress.
A good PM has a firm, but subtle hand on the tiller. They
guide the project with informed decisions, communicate clearly and often, build
and use relationships to get work done, they delegate, trust, monitor, measure
and have contingency plans. They do not seek to offload their responsibilities
or hide from the difficult projects. They know how to get things done and who
to go to.
Managing Changing Requirements
Unless you are running a very short, very limited scope
project, requirements will change. It’s how you manage this change that is
important. You can push back and remind the senior user whom signed the high
level requirements that they cannot change their minds. Or you can expect
changes, the first few demonstrations will also reveal changes to the original
requirements and design. As Senior Users begin to use the iteratively built
features of your software they will give you feedback which may invalid or
ideally fine tune the original requirements. This is great, this is what you
want your users to tell you. No point sticking to the original requirements and
design if no one wants the end product.
Roles & Responsibilities
I have sat in several meetings and asked “Who is the Project
Manager”, only to receive silence or “Who is the Scrum master?” and even once “Who is the customers/senior
user?”. Who is doing what and from that when. This forms the basis of a plan.
Otherwise you’re like a group of outfielders running around under a fly ball
all yelling “yours”. Without R&R you
cannot have a plan and without a plan, even a high level one, you chances of succeeding
are low.
Define whom you and what you need to do, add in a timeframe
and bingo, the elements of a good project start coming together.
Communication (previously known as Co-location)
About a year ago I would have sworn that co-location was a
key element in a project’s success. But since then I have completed 5 projects
working with a company based in another city, doing all the work remotely. Having clear R&R (as above) and
communications is the catalyst to co-location success. Since the person (or persons)
is not sitting next to you, you have to put extra effort into communicating in
a clear and concise manner. Start with a good plan and work from there,
ensuring that everyone knows what they are doing when. Actually I believe that
Non-Location maybe better for a project as it prevents you from assuming good
communications will come from simply sitting together.
Technical Factors (infrastructure & environments)
This used to be such a headache. I know I have an
Applications basis, but how many times has a project been delayed by waiting
for infrastructure to be built, configured, ports opened, firewalls changed and
soon on. Even in the days of virtual environments and clouds it can still take
time. Then there is the time and frustration cost of a failed migration from a
System Admin whom cannot follow instructions. Having a good Operations person
on the project is invaluable, days of waiting for database and file access turn
into minutes and migrations become seamless and hassle free. Frequently – and
often without realising it – they become one of the key project resources and
unsung hero. I can think of several where I currently work.
Human Factors (context switching & resource planning)
Managing a team of 20+ people includes a strong element
resource planning and management. Projects start, stop, pause and take off
suddenly. Though a variety of formal and informal communications channels we
are made aware of current or planned projects. We plan and resource
accordingly. We also had contingency based on project process. The aim of this
is to ensure a Developer(s) can stay on a project until completion and avoid
distractions. Which leads into context switching. In simple terms it’s an
overload of tasks (be it project or incidents) that prevents an individual
focusing on completing their work in quality and timely manner. Carefully
resource planning and project priorities
will avoid this from happening. The culture of the organisation you work
for can assist or hinder this process. I have heard senior managers tell me it’s
ok to have a Developer assigned to three active projects – maybe they should
learn/remember how to code and try it.
Catalyst & Gelling (Soft Human Factors)
Have you ever notice that there are certain individuals on
projects that others will listen to, whom are knowledgeable, willing to support
and help others and though not team leaders or managers, others will naturally follow
their instruction. Project teams will
naturally bond and gel around these people and their wisdom and knowledge
becomes invaluable. I have worked with a few people like this, they are
naturally intelligent, calm, patient and helpful. They will also often be very
modest and step back from the limelight and move onto the next project. They
know who they are, good project managers want them and good people managers
retain them.
Conclusion
Go through all the above factors and you come to the
conclusion that a successful project is not the result of good luck, but one of
good management . Good communication and the skills of an air traffic
controller juggling several planes in and outgoing also helps. that it all
involves people – whom understand technology
- but not technology itself. I will leave you with my favourite quote of
the year so far.
The major problems of
our work are not so much technological as sociological in nature. (PeopleWare
Productive Projects and Teams (DeMacro & Lister).
