October 01, 1999
URL:http://www.drdobbs.com/tips-for-better-project-leadership/184415778

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.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.