Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Tips for Better Project Leadership


Corporate Developer's Survival Guide: Features: Tips for Better Project Leadership

Corporate Developer's
Survival Guide

Good technical management is like good driving. When you do it right, no one notices, but when things go wrong, the detritus from the south end of the northbound horse hits the fan. Here, I’ve culled my top 11 team management tips from years of interviewing managers, reading books, and my own technical management experience. I didn’t prioritize them because I think you must view management problems orthogonally. Each perspective of a problem can reveal details that you might not see in other views.

1. Don’t make the same mistakes everyone else has been making for the past 20 to 30 years.

So says Steve McConnell, editor of IEEE Software and author of several best-selling software development books, including the classic Code Complete (Microsoft Press, 1993). “Read a lot” is further advice from McConnell, who suggests that only through reading can we find out what worked for others.

2. Eighty percent of management is picking the right people.

The other 20% is getting out of their way. This advice comes from Scott Adams, of Dilbert fame. A good project manager must create an environment where the “right people” can perform optimally—a facilitation process that Tom DeMarco and Tim Lister first described in Peopleware: Productive Projects and Teams (2nd Edition, Dorset House, 1999). This book is required reading for any project manager.

3. Always try to hire people who are better than yourself.

A project manager is only as good as his or her team; don’t let your ego distract you from your project’s goal. Assemble a talented team, give it resources and ground rules—and let the players take ownership of the problem. Then, follow Scott Adams’s advice and move out of their way.

4. Don’t squander your lead time.

Tom Bragg, chief technology officer of Intellisys Technology Corp., says he’s seen too many projects get into trouble because they don’t start on time. Common reasons for delays include people getting diverted by other tasks, fights over the organization chart, managers who don’t staff on time, and other similar time sinks. “Lead time is too precious to waste,” says Bragg.

5. Optimum is not maximum.

Another project management tip from Tom Bragg focuses on what happens after the project gets started. Bragg says, “Plan your work, and work your plan: crashing and burning is almost always counterproductive. There is an optimum work level, probably somewhere around an intensely focused 50 hours a week. Stick to it.”

6. Use realistic, non-biased estimates.

Bragg says that project managers should avoid the trap of tailoring estimates to management’s desires. A valid estimate, he says, “is the amount of time and money that has an equal probability of being high or low.”

7. Develop the right organizational structure.

Tom Malone, professor of information systems at MIT’s Sloan School of Management and director of the Center for Coordination Science, focuses on communication and coordination strategies in organizations. He is particularly wary of traditional hierarchies; “Anything that can be coordinated hierarchically can also be coordinated in a nonhierarchical or emergent way,” he says. Malone sees a process as having both surface and deep structures: the surface structure consists of the visible sequence of actions, whereas the deep structure represents the underlying meaning, goals and constraints of those actions. Once you’ve identified the deep structures, you can develop surface structures to effectively manage them. And, don’t be afraid to look far afield for viable models. For example, the team that develops the Apache web server’s open source software product shows how well a non-hierarchical meritocracy can function.

8. Utilize free tools on the World Wide Web.

At http://sunset.usc.edu/WinWin/winwin.html, you can download a tool that Barry Boehm’s students developed to meld Theory W (the WinWin model) with the spiral model. At the Project Management Institute’s web site (www.pmi.org), you can download its online book, Project Management Body of Knowledge. Or, at the Software Program Managers Network web site (www.spmn.com), you can review a “Statement of Best Practices,” which closely parallels many recommendations made by the Software Engineering Institute’s Capability Maturity Model. Also available at this site are two tools, Control Panel and Risk Radar. Control Panel is an Excel spreadsheet for monitoring productivity and quality; Risk Radar is an Access database to help quantify project risks.

9. Don’t overlook older developers.

Instead of hiring recent college graduates, consider retraining older developers. Older programmers frequently have extensive experience on multiple projects and are adept at picking up skills or understanding new requirements. Their experience and perspective can help younger developers (and project managers) avoid costly time and money traps.

10. Pick the right process model for your project.

One size does not fit all. At its Beaverton, Oregon facility, Intel gives software development groups wide latitude to choose the process model for their style. However, Intel evaluates every group’s performance regularly. If delivery time or quality lags, Intel encourages the group to improve its process.

11. Have a survival mode plan ready.

If your company is prone to reorganization, or if you see a re-engineering plan gaining support, be ready to go into survival mode. Peter Senge reports in The Dance of Change (Doubleday, 1999) that more than two-thirds of all corporate re-engineering efforts fail. To avoid becoming the casualty of a misguided missile, only commit to the most modest delivery schedules. You’ll need slack time to compensate for turnover, falling morale, and general inefficiencies introduced by the changes.

Remember, project management is a craft, not a science—you can’t quantify all of it. At some point, you’ll have to rely on your own intuition and experience.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.