10.31 Managing for Success: Day-to-Day Project Management Insights

 < Day Day Up > 



Anyone who has managed projects for more than a few rounds knows that something could always have been done during the course of the project to eliminate pain. Even the best Project Managers learn painful lessons. What distinguishes the best Project Managers from run-of-the-mill types is good memory and a willingness to be flexible. The following sections point out some areas of commonality shared by the best Project Managers.

10.31.1 Focus on Process

Everything moves according to plan. The plan is composed of multiple phases, each phase broken down into tasks and milestones. Everything that touches any aspect of the plan should be done according to some process, standard, or pre-agreed method. Good Project Managers never focus on individuals, but on the tasks those individuals perform. Everyone associated with work on a project is an equal cog in the big wheel. When project leaders stay focused on the processes that drive the tasks to completion and move the effort from milestone to milestone, they avoid the pitfalls of dependency on a few key individuals. They also demonstrate leadership and show an equality among participants. This mitigates pain.

10.31.2 Put Theory into Practice

Change control is a good idea. Quality is nice. Periodic reviews will help create a better understanding of what we are doing. This product should be tested using test cases developed during the development stage. Boy, all these are nice things to hear at the beginning of a project, but all too often, when time constraints put pressure (pain) on the project team, corners get cut in these areas. This is not the place to cut corners, folks. Change control is essential and should never be optional. Quality is demanded from sophisticated users and, personally, I would not want to deliver anything less than the best project I could put into reality. During the initial stages of planning, remember all these things that sound good—and take their implementation to heart. Putting theory into practice mitigates pain.

10.31.3 Detect Early Warning Signs

A team leader takes off for the weekend without submitting his weekly status report. Is that a problem? A developer misses a delivery date and you find out at the time it is supposed to be compiled into a larger drop. Is that a problem? Remember, in project management, everything is done according to a plan executed in an orderly and proficient manner. It is wise to question even the most minor deviations. Either of the above incidents could be the early warning signs of a larger problem—or not. The point here is that you must get down into the trenches and ask some questions to be sure. Emphasize to your team that missing deliverables is not the way to inform you they are running into problems. The team leader who took off without submitting his status report may have intended to submit it to you from home on Saturday morning or may have been so frustrated at his progress in the project that he decided to try and hide it. Either way, you won’t know until you go find out for yourself. Good project leaders are like bloodhounds; they can sense when something is not quite right, and they will begin to ask questions at meetings, probing into the issue until someone comes clean and confesses or the issue is answered to their satisfaction. Even the most trivial slips can be early warning signs of a much larger issue looming in the shadows. Think of these warning signs as tips of an iceberg and leap into action. Being proactive mitigates pain.

10.31.4 Set Communications Ground Rules

At the beginning of every project, I like to set the stage for all team members to feel free to open up and speak their minds about issues. In order to prevent this from turning into a melee, I have found it a good idea to establish some communications ground rules. Here they are:

Speak up and speak for yourself.

  1. Speak up when you have an idea or a problem; don’t let others speak for you in a meeting.

  2. Be constructive, be concise, and be to the point; be prepared to say what you would do to forward the idea or solve the problem.

  3. Be accountable for your agenda. Insist that others answer the questions you bring to the table unless (or until) there is a clear reason to move on.

Be open-minded.

  1. Listen actively; make sure others know that you’re listening. Be prepared to re-create what they said and how they felt about it before you share your point of view. Don’t interrupt—ever.

  2. Be patient with others’ need to develop their own thoughts; don’t interpret for them.

  3. Be willing to engage in constructive conflict. Hear out a new idea before you react. Separate the goal of understanding from the goal of agreeing with others.

Keep the team’s satisfaction and productivity uppermost in your mind.

  1. Encourage focus (i.e., finish a topic before you move on). Do not allow emotion to cloud an issue.

  2. Define consensus as completion, not unanimity. Ensure that all who need to speak have had their say and feels that they’ve been heard. You’re committed to support the decision as if it were your own.

  3. Plan and think things through before acting. Beware overcommitting. Seek needed input, and be considerate of others’ feelings.

  4. Create and use mechanisms for offline/nontask discussions.



 < Day Day Up > 



Managing Software Deliverables. A Software Development Management Methodology
Managing Software Deliverables: A Software Development Management Methodology
ISBN: 155558313X
EAN: 2147483647
Year: 2003
Pages: 226

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net