Smooth Projects... Effective Project Management!
Project Management Software Articles
Project Management
Project Managers, Must they be technically savy?
Smooth Projects Article Comments:
Must Project Managers Be Technically Savvy? By Luc Richard
“Must
Project Managers be technically savvy?” This topic always seems to
cause quite a stir. While some believe that all you need to manage a
project is a PMP certification, others are convinced that you can't
successfully manage a software development project unless you truly
understand the intricacies of the product.
I agree! To be
an effective Project Manager, you must know the ins and outs of your
solution. You must be capable of designing and developing the solution
yourself.
Here are 5 fundamental project management tasks
that Project Managers can't accomplish unless they have a strong
technical background and truly understand the particulars of their
product.
In order to create a project plan, you must be
able to estimate how much effort is required to complete all of the
required tasks. Needless to say, you can't estimate effort unless you
truly understand what's involved in designing and implementing those
features.
Unless you understand what's required to reach
5-9 reliability, you can't assess how much effort is required to
achieve this non-functional requirement. Unless you clearly understand
how to write Java Server Pages, you can't predict how much development
effort is required to transform an HTML prototype to set of fully
functional JSP pages.
Scheduling Tasks
Imagine
that someone hands you a list of activities that need to be completed
for a given project, along with the overall effort. Could you schedule
the tasks in a logical sequence? Should the developers start with the
presentation, the business, or the data storage layer? Which comes
first when working on a presentation layer: the HTML, the JavaScript,
the CSS, or the servlets?
A Project Manager must be able
to schedule activities in a logical sequence. If you can't determine
which activities must come first and which ones can be done in
parallel, you can't put together a project schedule.
Assessing Risk
Imagine
the following scenario. Your product is scheduled to be released in 5
days. The QA team discovers a defect in the API through a series of CLI
tests. After carefully examining the problem, you realize that you're
developers have been working around this defect for months.
Given
that you're only 5 days away from releasing your product, should you
fix this defect or document the workaround? At this point in time, how
risky is it to modify an API that's being used? How confident are you
that the developer can fix this API in the given timeframe? What's the
likelihood that changing this API will break the modules calling it?
Should you fix the defect now, or release the product and address the
bug in a patch release?
Unless you've seen the code behind
this interface, you can't answer any of these questions yourself. You
need to ask your developers. You're not the decision maker. They are.
Participating In Customer Meetings
Customer
meetings always end up in technical discussions. Unfortunately, if you
can't speak intelligently about your technology, you can't add any
value to such meetings. You're not participating; you're strictly
listening, and perhaps taking notes. Sooner or later, your customers
will find themselves contacting your developers directly. “Why contact
the Project Manager if he can't give me an answer? I may as well go
straight to the source.”
Ensuring Nothing Falls Through The Cracks
Let's
face it. You never get as much time as you'd like to plan your
projects. What's important is not that you get it perfect the first
time around. What's important is that you can catch the tasks that fell
through the cracks before it's too late.
If you don't know
what's required to complete your solution, you won't be able to
identify all the overlooked activities. They'll either be pointed out
by your developers, or simply omitted forever.
In Short…
To
be an effective Project Manager, you must be capable of designing and
developing the solution yourself. Otherwise, you have two options. You
can either (a) ask others to make decisions for you, or (b) simply
pretend you know what you're talking about. In the first case, you're a
Project Coordinator. In the second case, you're a Project Mangler.
Luc
Richard holds an MBA with a major in high technology. For the past 10
years, he's been managing the development of software applications. He
is the founder of The Project Mangler (http://www.projectmangler.com),
an online resource that publishes free articles, stories, and other
ready-to-use tools to help developers, team leaders and managers
deliver software projects on time, according to specs, and within
budget.
Article Source: http://EzineArticles.com/
|