|
Software Project Management Primer
By Taran Rampersad
Contributing
Writer
Article Date: 02.12.03
Sooner or
later, someone steps into your office and says, “You’re a project
manager.” It’s that quick, it’s that unannounced. It’s
as though it’s expected that, just by hearing those words, you’ll
magically know what you’re supposed to do, how you’re supposed to
do it, and when things are supposed to get done. If you’re very lucky, you’ll
increase your salary. If you’re like most, you won’t.
What’s more, you may have inherited a project that is already underway.
It doesn’t have to happen that way, but it does happen, and it happens quite
a bit. In the present IT and Development job market, it’s probably going
to happen more frequently. What makes it worse is that there is no standard job
description for a Software Project Manager.
You can read as many books and articles as you wish, you can get certified in
all fashions – the bottom line, though, is succeeding as a Project Manager.
It’s a lot like starting out in the IT world – the only real way to
learn is by doing, asking questions, and learning from mistakes.
Being in charge of a project can really be intimidating – and if it isn’t,
then you’ve either successfully done it before, had too much caffeine, or
don’t know what you’re in for. This article is for the people who
suddenly find themselves in a Project Management position and don’t know
what they are supposed to be doing – or how to do it.
Typically, people who tell you that you’re a Project Manager think that
you have the capability to do it, but they haven’t told you what is expected
of you. If you have a formal software process, you have it easier – you
can check the process, and see what you need – even look at past project
information and see what was done, and how.
If you take a few minutes and consider your experience, you may be pleasantly
surprised. Almost any job experience within IT prepares you for your role as a
project manager. If you’re a System Administrator, you understand how to
manage a complex network and to troubleshoot it. If you’re a Software Developer,
you know how to write software that accomplishes certain tasks. A project can
be approached either way.
You’re doing what you’re good at. It’s just a different
project. You’re projects are now projects.
If this is a brand-new project, you have to make sure quite a bit gets done. Typically,
when a new project manager takes over, there is a meeting. When a new project
starts, there is a meeting. When a project ends – there is a meeting. Go
in prepared with at least a pen and paper; the details are important.
Some things that are typical of starting a new project are:
· Proposal Writing: To free up funds/resources for your project.
· Project Costing: How much it will cost, including resources and time.
· Project Planning: And Scheduling: Landmarks, milestones and such.
· Personnel Selection/Evaluation
These four items are important for starting up. If you’ve inherited the
project, you’ll want this information immediately so that you can check
and see where the project is, how much money you have in the budget, what milestones
have been met, and which ones need to be met. If you don’t know how to do
these things at your company, start asking questions. You may not need to do the
proposal or project costing – it may be your boss’s job, for instance
– but you should be aware of the information.
Unfortunately, if you’re replacing someone who left mid-project, that individual
probably wasn’t giving his or her best to the project - it may be either
behind schedule, over budget, behind schedule, or all of the above. Stand by for
heavy rolls in high seas! At least you now know where the project is – and
can therefore have a positive effect on it. Once you have this personal baseline,
which is a snapshot of how things are going within the project now, you can share
this information with your boss, so he or she knows what the status is.
If you don’t have a formal process to work from, take time to sit down and
think about what is expected of you. Think of the specifics of the project, and
get the perspectives of everyone on the team both as individuals and as a group.
This includes your boss as well; though you may not realize it, he or she is an
integral part of your team. How active your boss is on the project depends on
you.
Historic project information (if available) is a treasure trove to the beginning
Project Manager. Simply reviewing past projects is a great way to learn the ropes,
because you gain the benefit of learning from mistakes made by others –
and if you’re smart, you won’t repeat them.
Where a lot of people seem to go wrong here is that they don’t ask questions,
instead thinking they can hack their way through. Sometimes that works –
and sometimes it doesn’t. Either way, asking questions of people who have
handled projects at your company – or the person/people Project Management
reports to – can save you a lot of time, frustration, hair and Pepto-Bismol
™ (or whatever new brand that the pharmaceutical companies have sold
you).
Once you have these items under control (easier said than done) bear
in mind that you’ll need to revisit them at least before every meeting with
the higher-ups. Keep this information handy at ALL times! Remember that they may
not care how ‘cool’ the project is – they are interested in
two major things: Schedule and Cost. If you can keep those two up to date
in every meeting, your superiors may not notice that your socks aren’t matching,
or that you aren’t wearing any.
If you have to select personnel for the project, be careful. Remember that you’re
going to be busy doing other things (like meetings) – so don’t think
you’ll be a major hands on participant on the project. Select personnel
based upon the needs of the project and choose team members for their strengths
and abilities. Be aware of their weaknesses as well, and also note how they work
in a team. A whole article could be dedicated to this particular area; it is difficult
for even a seasoned Project Manager to do. It’s even more difficult for
the beginning Project Manager who has to select from a pool of co-workers. A
whole book could be written on this alone, but a future article may have to suffice.
Personnel evaluations may be as easy as following your company’s procedure.
Be careful here, especially if you have former equals on the project. There’s
no room for ego from yourself or any other member of the team when it comes to
completing a project.
Aside from keeping tabs on everything mentioned above, you need to have
a handle on the following areas:
Project Monitoring and Reviews
Report Writing and Presentations
Both of these areas are more demanding than they sound and will demand a lot of
your attention.
For Project Monitoring, you’ll need to look at the daily events of the project
– as well as the weekly and the monthly – and see how everything affects
the outcome of the project. This can be difficult when it comes to small problems
that aggregate, like a poorly written requirement that caused a design decision
that works against you in the project. Then there is the ever-present Requirements
Creep, and setbacks, like losing a key person on the team. When you factor monitoring
and reviewing in with budget(s) and schedules, you don’t need water to create
an instant headache.
But if you manage the project carefully, collect the right information, and evaluate
it – your headaches are minimized. If you see warning signs indicating someone
is about to leave, you can take action. If the requirements start to creep, you
can bring it up with your boss, and mention how schedule and cost will increase
accordingly.
I’ll throw in here that “classical” project management (whatever
that really is!) neglects to use all of the tools available. Sure, everyone
is punching out emails, but – who’s doing it and when? Do you want
your team members staring at their inboxes like a bad AOL commercial, or would
you rather have them check their email one to two times a day for project information?
Do you want them tied up in meetings, or would an email report suffice? Email.
Consider instant messaging. An intranet site that everyone – including your
boss – can check. Consider blogs! Look around, and even peek at
what makes all that Open Source stuff so successful – those teams probably
have never been in the same room together!
You’re driving; you might as well pick the radio station. Just make sure
everyone can tolerate the music, or you’re going to have problems.
Report Writing and Presentations can be a real bore, but as an IT professional,
you can find your skills useful here. Sure, you’ll still need to write
things down, and present them to management – but as an IT
professional, you have a toolset that most bosses don’t realize you have
until you tap into it. You can probably automate a lot of the reports. Throw in
the fact that there are many tools already available to help you – you’re
well on your way!
You can even save some writing. Emails from your team members, your boss, everything…
Those can easily be incorporated in a report. You do have to be careful what is
passed along. Remember who is reading the reports, and how they may perceive things
written down.
There’s a danger when management becomes concerned about a project and it
leaks to the project team. I think everyone has seen what happens, and we can
all agree that the aftermath is ugly. Conversely, telling management The Natives
are Restless is also a bad idea – you have to think of yourself as
a buffer, only you can filter what goes back and forth.
Think of reports and presentations like you think of websites. If they look really
pretty but have no content, they are worthless. If they have a lot of content
and look ugly, they tend to be ignored. You’ll have to find your own balance
and style that works for you.
Not quite. Being a project manager is a delicate balancing act, and requires practice.
As a project manager, you can go in many directions. The most important thing
to bear in mind, however, is that someone or some group of people has entrusted
a project to you – and the people that are working on the project depend
on you for guidance, for support and to act as an intermediary.
I’ve worked on a few projects that management considered successful but
were failures in my eyes. I saw how things could have been improved given more
of the right resources, and a longer schedule. Yet there is one thing that every
person working on a project who collects a paycheck must remember (and this includes
the project manager!) – the project was undertaken to meet the business
needs of your company. Those business needs are subject to change at any time,
and adaptability and patience are key
About
the Author:
Taran Rampersad, also known on the Internet as ‘ CoolNameDenied ‘, is a
Writer/Developer/Consultant and can be reached at cnd@knowprose.com. His personal site is
http://www.knowprose.com.
|
|
