14 Ways to Succeed at Project Management

14 Ways to Succeed at Project Management

By Paul ConteManaging software projects is a tough job with no "cookbook" that guarantees success. If you didn't have to meet a schedule and budget, it wouldn't be so bad - after all, you're rarely called on to write software for the next NASA lunar landing. But creating a schedule and budget has dogged every project I've ever worked on. What's worse, the organizations I've worked for actually expected me to come close to meeting both! To combat those unreasonable expectations, I've adopted tactics that give me a fighting chance to make the reality of a software project somewhat resemble the fantasy that so many project management textbooks describe. I've learned a few tricks from my own experience with medium-sized projects (you'll want more than this article offers if you're managing a really large project) and picked up other practices from reading or listening to the experiences of people who've led their own projects. So, with humble appreciation for how difficult it is to manage a software project, I offer my personal list of 14 ways to have a better chance of success.

1. Start with a one-page, written development process.

If budget, schedule, quality, or application capabilities matter, you need some identifiable list of steps for your project team to follow. At the same time, most small to midsized MIS groups don't have time to create and follow a three-volume, NASA-level development methodology. You can make a reasonable start by spending a quiet evening after normal working hours typing up one page that lists in outline form the major steps to follow in a software project. Over time, you can expand this document to provide more detail.

An easy way to get started is to "steal" steps from a good book on project management. Two of my favorites are Surviving Object-Oriented Projects and Use Cases Combined with Booch/OMT/UML (for information about these and several other project management resources I recommend refer to "More Help for Managing Software Projects". The former is more down-to-earth and the latter more formal. Don't take the easy way out and write something like "Step 1. Follow the steps in Use Cases Combined with Booch/OMT/UML as your one-page "development process." You want a practical set of steps that fits your organization.

There's not space in this article to discuss the possible steps you might include, but with some consideration of your past experiences bolstered by a little reading, it's not too hard to come up with a process that fits your situation. You can tell whether you've got a useful development process if it answers three questions for a developer:

When am I ready to move to the next step? (This might say what work products are produced.)

What is the next step? (This describes the order and activities of each phase.)

How do I move from the current step to the next step? (This covers how to use the results of one step in the activities of the next step.)

When you start with a simple description of your development process, you'll end up figuring out many of the details as you go along. With iterative development (see item 2), this doesn't pose as big a risk as it might seem. Also, to start, you'll verbally communicate to team members many of the specific ways to carry out each step. That's okay, too, because it may take an iteration or two before you settle on the best way to work.

As you move along in a project, capture in this "Project Development Process" document those practices that can be clearly described in a few words and that are most

important for team members to follow. This doesn't require writing a book, and over time you'll have a valuable guide for current and future projects.

2. Deliver real stuff early and often.

In a fantasy world, projects can be run according to the "Big Bang" theory: do analysis, do design, do implementation and test, and finally, deliver the production software. I've never seen this approach succeed with a nontrivial project. An iterative and incremental approach results in less risk and better results.

An iterative strategy means you expect to repeat and rework each phase of development (analysis, design, implementation, and so on) several times. An iteration may cover all or only some development phases; for example, a developer may deliver two releases of code in iterations that don't involve analysis or design work. Other iterations may span multiple - for example, going back to the analysis and design phases to identify and design additional features before implementing them.

An incremental strategy means you identify individual deliverables that are smaller than the whole work product from any development phase. The most obvious example is to identify specific implementation releases that the user can actually run. But many increments are smaller than a release and are nested within larger increments. For example, an AS/400 service program that provides two callable procedures could be a defined increment.

Iterative and incremental development go hand in hand but describe different aspects of the project flow. Repetitive, cyclic work on different project phases is what makes a process iterative. Producing clearly identified "chunks" (e.g., of specifications or code) gives a project an incremental structure.

Iterative and incremental development isn't hard to do, but you have to spend some time setting up a schedule that identifies the increments, the periods during which you work on each phase of each increment, and, of course, your delivery date for each increment. You should identify at least several points in the schedule when a release will be given to end users for feedback. These may be prototype, pre-production, or production releases. There's no hard and fast number of releases you need to produce, but one release every one to three months is about right for many projects. Remember, a release doesn't necessarily have to be a production release.

Why is it so important to use iterative and incremental development? Why not figure out all the requirements before doing a comprehensive design? Delivering part of an application to the end user before you've completed all the analysis and design means some deliverables may be wrong, have less than optimal user interfaces, or be inefficiently implemented. That's right. But you'll invariably have the same problems if you try the Big Bang approach. You have to get early and continual feedback to learn what's really required and to discover the truly best design and implementation.

The other crucial flaw in the Big Bang approach is that you may discover - very late in the project - large implementation problems that never occurred to you when you first planned the project. (Alistair Cockburn calls this "what you don't know you don't know.") With iterative and incremental development, you adjust your schedule (and other aspects of your project plan) as you learn from experience. Iterative and incremental development is also good "politics" (see item 14) because it builds project team and end-user confidence (or if not, then it helps by revealing deep organizational troubles early in the project).

3. Identify risks, and protect your project from them.

A well-done plan that's based on everything going "normally" is all you need - until something goes wrong. Battle-scarred project managers have learned to identify major risks at the beginning of a project and estimate the probability and impact (in time or money) of the risk. Then they take three actions:

1. Calculate a contingency for each risk.

2. Add project actions to minimize the likelihood and impact of the risk.

3. Add actions to monitor the ongoing probability and impact of the risk.

As an example, let's say your "normal" project plan depends on a key developer who's trained in object-oriented design and is the architect of the new shared class library you plan to build. What will happen if this person leaves or is unable to continue work? One alternative is to hire outside help, which may increase the staffing cost by forty thousand dollars and delay the project by two months. Another alternative may be to train a fairly experienced developer (if you have one) to step into the role of architect, which may increase the staffing cost by twenty thousand dollars and delay the project six weeks. If your company pays well and you believe the key employee is fairly content in his or her position, you may estimate a 25 percent probability that he or she will leave or be unavailable. That means you need to add a contingency of .25 times the impact of this risk to your project (e.g., roughly ten thousand dollars and two weeks or five thousand dollars and one-and-a-half weeks). Although many of the potential risks you identify may never happen, if you ignore them altogether, your project schedule and budget are likely to be too optimistic.

You can also take actions to lessen the likelihood and impact of a risk. In this example, you might establish "bonus" compensation (e.g., money or paid time off) for the architect when the project is completed, take out "key employee" insurance on the architect, or increase the preparatory training of a potential "apprentice."

Iterative and incremental development (item 2) is essential to risk management. As mentioned in that discussion, it's "what you don't know you don't know" that'll blow your project apart. With iterative and incremental development, you get early information about all aspects of the project, including different technical phases (e.g., analysis, design, and implementation) and inter-organizational activity. Adjust your risk assessment (along with the schedule and budget) as you discover more about what you're trying to accomplish and the people and other resources you have to work with.

4. Use pilot projects to estimate.

How do you estimate how long a project will take? You consider how long it took to do something similar and try to extrapolate what you have to do for the new project, right? What if you've never done anything similar - say you're doing your first Internet project and all you've ever done are green-screen applications? If it's a small project, you might get away with a guess - and who cares if you're off by a week? But for larger projects, a well-measured pilot project is your best hope.

For the pilot project, try to identify capabilities you can deliver in five or 10 percent of the time you initially guess the whole project will take. You want a project that covers the pivotal "unknowns," but you don't want a pilot to take half the time it'll take to do the whole production version. Don't focus just on coding, either. The largest unknowns may be such things as getting agreement on clear requirements definitions from end users. Carefully record both time spent and dates that tangible items were delivered. It helps to keep a daily diary to record observations on what problems occur and how they impact the pilot.

Even with a pilot, it's tough to extrapolate a full-scale project. As a rule of thumb, the rate of implementation should be higher for the full project than for the pilot because developers will get more experience as the project progresses, and there will be less time lost from "task switching." Tasks that require communication between people will usually take longer (per deliverable) for the full project than for the pilot because more people will be involved and communication may not be as efficient.

Be prepared for your organization not to want to do a pilot when you really need it - before you provide even the earliest estimates. The reasoning often runs like this: "We'd like to have a 'rough estimate' (right!) of the project schedule and cost before we decide to spend the time and money for a pilot project." If you fall into the trap of providing a "rough estimate" for a nontrivial project that requires doing something you're not familiar with, you're in trouble from the start. Once you've given an initial estimate - no matter how "rough" you label it - people will remember "six months" or whatever guess you made and won't be receptive to a significantly longer estimate based on the pilot. You also may unconsciously drift toward an overly optimistic extrapolation of your pilot results to stay close to your initial estimate.

Depending on the nature of the project and how much you trust your crystal ball, you can approach a pilot project as either a "throwaway" or a preliminary release. That is, you may start from scratch after the pilot, or you may try to build on it. I'd advise you to sell any pilot as a throwaway, if you can. Then, if some or all of the pilot turns out to be reusable, you've gotten a small gift. By approaching a pilot as a throwaway, you can cobble up parts of the application that aren't the focus of your exploration (be sure to take this into account when you extrapolate the whole project), potentially reducing the time required to complete the pilot. A production-quality pilot may give you slightly better data for estimating, but the improved accuracy may not be worth the effort. Remember, with iterative and incremental development (item 2), you should get additional feedback to improve your estimates as the project unfolds.

5. Expect change, and manage it.

Here are a few of the things likely to change during a software project: the requirements, the design, the implementation, the end users, the available platforms and tools, and sometimes even the project team members. Iterative and incremental development (item 2) helps deal with many of these changes. And you can take steps to keep your project team stable and prepare for the loss of a key team member, if that happens (item 3).

In addition, you'll avoid a lot of headaches if you have a defined process for evaluating and incorporating changes to the project requirements, design, and implementation. The changes to be concerned with are ones that happen after you think you've completed a deliverable (e.g., a new requirement gets added after you've produced a project budget and schedule based on an agreed-upon set of requirements) and that might significantly change the schedule, budget, or risks. Model your approach on what building contractors do: every proposed change gets a time and cost estimate that must be agreed to by the "customer" (for a software project, this is usually a department or upper-level manager). When estimating the schedule impact and cost, be sure to account for ways the extra work may throw other dependent tasks out of synch. But don't sweat the trivial stuff: If developers can tweak an interface with 15 minutes of additional work, they can safely make the change without processing a formal change request.

I'd never embark on a software project, no matter how small, without some form of source code versioning tool or procedures. The basic requirement is that you know the reason(s) for a new version of source code and can compare two versions (preferably with an automated source comparison tool) to see exactly what changed. Source versions are naturally tied to implementation releases, although it's not unusual to have developed several versions as you work towards a release. (Note that in standard software configuration management, or SCM, terminology, "version" and "release" have a somewhat different meaning than IBM uses in OS/400's version-release-modification nomenclature.)

You can get started with simple commenting standards or, if you keep your source in PC files, with a low-cost or freeware source version control product. For large projects, especially in situations where three or more programmers may be working on shared source code (or other project artifacts), look seriously at working up to one of the comprehensive SCM products available for the AS/400 and other platforms.

Using an SCM product presents a couple of hurdles. First, you may not be able to find an SCM product that handles versioning for all the kinds of code and other artifacts your project uses. For example, a product that handles AS/400 CL and RPG source code and OS/400 objects may not handle PC- or Integrated File System-based (IFS) Java source and class files. My advice is to start modestly and get some experience using versioning before you decide on a single "galactic" solution. Concentrate on source code versioning and setting up a simple "check-in/check-out" process because these steps can yield substantial benefits without a lot of effort. This may mean you use only a few features of two or three products (e.g., one for AS/400 source and one for PC source) or you use tools for some items and manual processes (e.g., commenting) for others. The solution may not be ideal, but you can learn which approaches minimize the effort required yet let you keep track of software versions.

The second hurdle to jump with SCM products, and change management in general, is dealing with "emergency" software fixes that require immediate attention - not uncommonly, outside normal work hours. Such changes can lead to parallel "branches" of source code and bypassing the normal quality checks and "promotion" process to move a new version from development to production status. Recognize that this type of change won't arise until an application goes into production use; so, even if you can't resolve all the change management issues for production systems, you can still use SCM tools for the initial development period of new applications. There's also nothing wrong with allowing exception cases to be dealt with in an ad hoc manner, as long as this doesn't become an excuse to ignore the change management process altogether.

6. Set priorities, and follow them.

You know the old saying: "Feature-rich, defect-free, delivered quickly - pick any two." This wry proposal reflects a problem with many projects: everything is "high priority." Developers know it takes time to increase function or improve quality. It also takes time to improve an application's speed, to polish the user interface, to develop test cases and scenarios, and so on. So, categorize the relative importance of the functions that go in each increment (see item 2) and be ready to meet a delivery schedule by excluding less important functions. Likewise, accept that you may produce a release that has known, but not critical, defects or deficiencies if you don't have time to fix them before the scheduled delivery date for the release. (You'll be in good company - IBM and Microsoft follow this practice.)

The acid test of whether you have truly established meaningful priorities is when some desirable goal has to go unmet: a function is missing, a flaw is left in the release, or the schedule is slipped. Sometimes there's no choice but to slip a schedule, but in many cases it happens because no one knows what else can be sacrificed to keep on target. Working without priorities can also result in developers working on expendable items (e.g., adding features or "gold-plating" quality) early in the schedule when there appears to be lots of time and discovering too late that there's not enough time to complete the remaining essential items. With clear priorities, developers can work iteratively (see item 2) to accomplish the most important items first and then work successively down the priority list.

7. Minimize dependencies.

In my experience, the most troublesome scheduling failures come from underestimating the potential implications of people and task interdependencies. Too many times, I've not allowed enough time for tasks that require close synchronization of three or more people, and I've missed the "expanding ripple" effect of a delay in the delivery of an item that lots of other tasks depend on. If nothing else, be sure you allow for these problems by increasing your estimates and contingencies (see item 3). When possible, however, try to attack the root causes by minimizing tasks that require more than two people (and if more than two are required, the fewer, the better) and by using a broad and shallow application design and project task structure. That is, avoid deeply nested dependencies (such as in new object-oriented class hierarchies).

But wait - doesn't more communication among developers and users involved in the project result in a better understanding of what's to be done? True, and it's fine to keep everyone informed and to allow for their feedback. What you want to avoid are tasks that require continuing, synchronized effort by three or more people.

You may also give up some potential code reuse by opting for a broad and shallow application design rather than a deep and many-layered one. You have to strike a balance; the longer time required to create deep structures that maximize reuse may result in lower life-cycle costs for long-lived projects (an extreme example might be an operating system, such as OS/400) or for software that's sold commercially. For business applications developed in-house, you're usually better off with fewer dependencies. You'll still be able to reuse plenty of code; just don't set your sights beyond the opportunities that can be exploited fairly quickly.

8. Have a realistic, but tight schedule; keep it honest.

Schedules are challenging because not only do you have to estimate the time it will take to do each part of a project, but you also have to consider interdependencies among tasks and the availability of people and other resources. Unpleasant as it is to create schedules, you're doomed if you don't have one or if your schedule's patently unrealistic. Not that it ever happens in real life, but you also don't want a schedule with too much time. People work most productively when a schedule is demanding but can be met.

A schedule needs more than five dates for "Analysis Complete," "Design Complete," "Coding Complete," "Testing Complete," and "Placed in Production." The end users mainly care about when they can get their hands on each release (see item 2). The developers care most about when they have to deliver a tangible document, program, or other artifact.

For anything but simple projects, you may find helpful a tool, such as Microsoft Project, that lets you plan and track tasks and deliverables. At the cost of having to buy and learn another piece of software, you can get a tool that automatically generates a calendar schedule from your list of task durations and dependencies and available people and other resources. If you use software to plan and track a project, don't be fooled into thinking that adding more detail will necessarily improve the accuracy of your estimated schedule. You can squander a lot of time entering and updating nonessential minutiae that lacks valid estimates of time or misses key external dependencies (e.g., the availability of end users to work on requirements definition). Keep the granularity reasonable and relevant to the things you can check on as the project progresses. Use iterative and incremental development to adjust your estimated schedule as you go.

9. Use fewer, better developers.

I believe in the rule: "People are the pivot." Most project managers I've met share my intuition (and there's some research data to back this up) that over the long run, a top- level analyst or programmer can produce 10 or more times what a mediocre analyst or programmer produces. You usually get better quality, as well. The exact ratio isn't important; a two-to-one advantage would still lead to the same project management tactic: get good people, retain them, and help them do their best.

I know you don't always have a choice - your boss may have assigned you a tough project and put a real dud on your team. This is such an important determinant of your project's success; however, you should fight for good people as hard as you can. If you end up with weak team members, you may see an opportunity to improve a worthy candidate's skill level by training - the problem is that increasing a person's skill level often requires months of training and experience, and your project may not run long enough to benefit. After allowing for training opportunities (and costs), be sure to factor your team's relative strength or weakness into your schedule.

There are a lot of wrinkles in this idea of the "top-level developer." Obviously, when I use the term "top-level" it's shorthand for skilled, experienced, and motivated for the tasks you want a person to perform. A great Java programmer may be a mediocre analyst due to lack of skill, little experience, or disinterest in doing analysis. For the record, my definition of a "top-level" developer also means a person with integrity, who has good work habits, who works well in team situations, and who demonstrates a myriad of other nontechnical talents and positive attitudes along with his or her specialized skills and experience.

Don't expect a top-level developer to produce his or her maximal ratio over an average or mediocre developer until the task involves a substantial amount of work. For example, if you expect an "average" programmer to spend 100 hours on a particular implementation, you might expect a mediocre programmer to take 200 hours and a top-level programmer to take 20 hours. But for an implementation that's half the size (e.g., in features or function points), you might expect the average programmer to take 60 hours, the mediocre programmer to take 110 hours, and the top-level programmer to take 15 hours. As the project gets smaller, the start-up time can only be squeezed so much, even by the best developer.

Of course, even potentially dramatic productivity ratios affect only the time spent working on the respective tasks. If coding is 20 percent of a three-person, five-month project, the coding effort represents three work-months (at most). If the coding work is spread evenly among two people, each has 1.5 months of coding to do. A 10-to-1 ratio in improved coding productivity represents a theoretical reduction of 1.35 months in the overall schedule. If you factor in limits to how much you can compress coding (as discussed above) and allow for less than perfect utilization of the "saved" time, you might realistically expect to save two or three weeks. So, don't overestimate the net savings from using more- capable team members.

On the other hand, if you can knock two weeks off a five-month project, that yields hard cost savings and potential benefits from earlier deployment. Equate the savings and benefits to developer salaries and other employee benefits required to recruit, train, and retain top-level people, and you can decide whether you're better off with top-level, average, or mediocre people. My experience has been uniformly that the lowest-cost projects are done with the "best" (not always the most expensive, by the way) people.

When you have a small team or need a wide diversity of skills, you may not find the one or two people who are "top-level" for all tasks. Assess your options for matching potential individuals or teams, along with outside help, to the project, and choose the mix that keeps your risk low (see item 3). If the risk comes from technological innovation (you're doing your first major application in Java), strengthen the design and coding side of the team. If your risks are from ill-defined user requirements, strengthen the analysis side of the team. You may have to allow more time to complete the tasks if the team is weaker than you'd like, but you'll reduce the chance that the project will blow up on you.

10. Give your team a quiet environment and top-quality tools.

Multiple-choice question: Developers get more done when they:

a. work amid ringing phones and conversations in the next cubicle spilling over the partition

b. work in a private office where they can close the door and turn off the phone's ringer

If you answered a, skip to the next item in this article (and don't tell your team members). The right answer is b - one research project found that highly skilled developers are two-and-a-half times more productive in a quite, private office than in a noisy "open" environment. Consequently, fight every battle you can for private offices - even tiny ones with no windows or other amenities. Developers need uninterrupted, quiet time to think and design or code.

The kind of office environment you give your developers has a broad effect: private offices magnify the best producers' productivity, while an open-partition workspace magnifies the time "slackers" waste - not just their own time, but that of everyone around them. In my experience, top-level developers also rank private offices high on their list of benefits and, once they've become accustomed to a private office, would think twice before taking a job that put them back in the melee.

Here's another test: How much improvement in productivity is required to get a good return on a five hundred dollar tool? Taking into account salary, overhead, learning time, and upgrade costs, a rough figure is about one percent return for every hour of saved time. You can do quick calculations to develop a reasonable return-on-investment for specific tools, but in general, good tools and fast development machines are an excellent investment. The benefits from tools multiply with the increasing ability of team members (top-level developers know how to select and use tools more effectively than mediocre developers).

11. Automate standards with tools.

Sensible standards for requirements documents, coding techniques, and so on are important. Standards can significantly aid comprehension of documents and code and can reduce errors both through better understanding and from the reuse of time-tested coding techniques.

Make standards easier to follow by using tools that automate them. In my experience, developers generally like time-saving tools that produce standard documents or code (as long as what's produced is of good quality), but they abhor lengthy standards manuals. You can go "high-end" with tools such as code-generating "CASE" products or go "low-end" with Word and Excel templates, standard Visio graphic elements, or source code editor macros. Even "cut-and-paste" templates of text or source code can be a reasonable starting point.

12. Know where the project stands.

Several times a week, a project manager will face the question: "How far along is the project?" You've got to have an answer. That means either you lie - my favorite version is telling the questioner, "We're about 80 percent complete," and saying to myself, "with 80 percent left to do" or you hand over a piece of paper with a list of concrete deliverables and a check mark beside each one that's been delivered. It's amazing how much it changes your perspective when you face handing someone a list with no check marks!

There are lots of variations to this theme. Here's one simple approach. Keep two lists:

a list of application functions (recognizable to end users)

a list of concrete deliverables (i.e., increments, recognizable to developers)

The second list will be longer than the first and will include artifacts such as design documents that aren't of interest to end users. Form a table from each list by adding columns for the planned iterations. In many cases you may plan only two iterations: Initial Version and Final Version. An initial version is one that's useful but either incomplete, not fully tested, or in some other way needing of more work. A Final Version is one that requires no more work. For some items, you may plan several iterations (e.g., implementation releases), which you can reflect in your tables' columns. Check each cell in a table when the respective iteration is delivered. A quick look at the table will tell anyone a lot about where the project stands.

I don't put much stock in any method that estimates how complete a deliverable is. What meaning can you gain from a developer's statement that he or she is "80 percent complete" on a particular program? Concentrate on "binary" measurements: done or not done.

With the system I've just described, you can weight the priority (or value) of each item and sort your tables so the most important items are at the top. This makes it even easier to see what's getting done as time marches on. As you might expect, this reporting technique is best suited to an iterative and incremental approach (see item 2).

13. Have someone own every defect.

Defects are more costly than many project managers appreciate. They cost time to discover and fix, they can have a magnified impact due to the expanding ripple effect (see item 7), and they're bad politics (see item 14) because they reduce the confidence of team members and end users. There are various formal approaches to testing and quality insurance that may help reduce defects, but in my experience, these ex post facto strategies are less cost-effective than one simple idea: have every defect "owned" by someone. This doesn't mean ridiculing a developer for a coding "bug"; the process can be much more benign, as I'll explain.

One group I know of at Hewlett-Packard reviews each defect report at its weekly project meetings. The process identifies where the defect was introduced (e.g., design or coding), and then the person (or people) responsible for the defect explains how he or she thinks the defect arose and what might be done differently to avoid similar kinds of defects in the future. The project leader is careful to focus on improving everyone's effectiveness at avoiding defects, rather than on "blaming" individuals. Nevertheless, no one relishes the distinction of explaining to other team members how they might avoid a mistake the developer made.

Almost every developer I've worked with pays lip service to "quality," but many of those same developers aren't really aware of how much room for improvement there is in their defect rate. The keys to reducing defects are to record them and have personal ownership of them. These principles are quite simple, but they require careful thought to put in practice. For one thing, don't tightly couple this process to performance evaluations or rewards. The driving force comes from shaping developers' understanding and individual concern for defects, rather than from some organizational "carrot-and- stick" mechanism. (Obviously, in exceptional cases, excellent or shoddy work merits consideration in performance evaluations.) Also, be sure to consider the nature of what's being worked on when you discuss defects. Code for a throwaway pilot project is supposed to be done quickly, and that leaves room for a much wider range of acceptable defects. You're sure to frustrate valuable team members if you insist on discussing the defects in their work for a task such as this.

14. Practice good politics.

Now, after all this advice about running a successful project, I should mention what really determines how most projects are initially set up and ultimately regarded by the organization outside the MIS department: politics.

Wouldn't it be wonderful if you could present a realistic project strategy - for example, conducting a pilot before estimating, hiring top-level people, and providing training and tools to leverage their skills - and have this strategy rationally considered by your organization's management? More likely, as you discuss schedules and budgets, you'll have to navigate interdepartmental squabbles, deal with managers who trot out the old "My kid in high school says he can create a Visual Basic program to do what we need in a week!" and a slew of other frustrating hurdles to doing your job well. We all understand why Dilbert strikes a chord. There's not room here to discuss how you can deal with a less than ideal organizational setting for your project. Just be aware that a broad study of failed projects found lack of management support and lack of end-user involvement to be the two most frequently cited causes of project failure. And keep in mind that you'll need to adapt your strategies to the dynamics of your managers and peers if you want room to practice good project management.

Politics plays a large part in the final impression of a project, as well as in its inception. We all know of a hard-working team whose best efforts went unappreciated because the rest of the organization knew little about the obstacles the team had overcome to complete the project. Conversely, there are plenty of examples of bloated project teams taking longer than necessary to deliver inferior applications to an organization that, despite the evidence, thinks MIS is doing a good job.

When you manage a project, spend at least a little effort keeping abreast of how the rest of the organization perceives your team (and department). You don't have to "sell" your project, but by keeping your focus on what matters to your "customers" (the end users), especially those that influence the opinion of other workers and managers, you can foster more appreciation for your team's efforts. Iterative and incremental development establishes credibility and provides ongoing opportunities to engage end users in a variety of project activities. This type of interaction usually creates better relationships than the Big Bang approach. With the latter, first the analysts descend on the end users with implicit demands that they define all their needs; then all is quiet for a long time during design, coding, and testing; and at last the application - which turns out to be a lot different than what the end users actually wanted - is delivered in a rushed period of training and start-up. Often at the end, tensions mount, blame and excuses fly back and forth, and there isn't any history of ongoing small successes (and small failures) to fall back on.