Q
Problem solve Get help with specific problems with your technologies, process and projects.

Successful project management: It's the person, not the process

Processes can help guide project management, but it's the person driving the project that will make it succeed or fail. Site expert David Christiansen explains.

I am one of those project managers that's sometimes called a cowboy. I make a lot of decisions on the fly, and I typically don't plan (in detail) more than about six weeks in advance. Ironically, my projects tend to be pretty successful and other project managers keep asking if I could teach them my project management "process." I feel like my lack of a process is one of the reasons I'm successful. Could there be any truth to that? Could I bottle my cowboy ways up into a process that others could follow?
Here's a cycle I've observed many times in my career. I call it the "FSOP Cycle" -- the "Flying by the Seat Of your Pants Cycle". Frankly, I've gone round and round this thing many times as I try to apply successful patterns/approaches to broader problems than they were initially used. I hope it will help you to understand what is happening as others observe the successes you are having.

Incidentally, there are no arrows on this cycle because Apple's KeyNotes software can't draw curved arrows. Aargh. I'm going to have to break down and buy office on the Mac or learn more about OpenOffice. Sigh. At any rate, the cycle moves clockwise.

This cycle is really the application of Virginia Satir's model for change to the problem of how processes evolve.

I made this up yesterday as I contemplated the usefulness of process in the context of software development. I've really lost faith in the idea of the repeatable development process, an idea that seems to be the holy grail of many IT professionals. Is it myth? I think so. I don't believe process can do much, if anything, to guarantee a development project will be a success. That's like saying anyone can invent flight by following a certain process or discover the so-called Northwest Passage using another defined process. It doesn't make sense.

Process can help you keep track of financial expenditures, staff allocation and other peripheral (but important) aspects of a project, but it can't guarantee success. And heavyweight processes often guarantee failure because they put an unmanageable burden on project participants.

I believe there is an irrational association between project success and process adherence on the part of many IT professionals and pundits. I don't see a correlation, and I've been on lots of projects in the past 10 years. In fact, the successful projects I've been on were usually not encumbered by stringent processes. Instead, they were composed of smart, motivated people who were flying by the seat of their pants. I don't mean they were just making it up as they went along -- quite the opposite. They always had a plan, and they revisited it constantly, sometimes everyday. They were focused on making progress, getting rid of obstacles, and adjusting plans to use resources as effectively as possible. They were planning every day -- but not for long. Brief, daily planning coupled with focused activity toward an immediate goal is the only "process" I feel comfortable with today.

Even then, I want to bring up a point. I don't necessarily believe this process will guarantee project success either. No process could have helped Lewis & Clark find a Northwest Passage because there isn't one. Some things are impossible, and processes -- even lightweight ones -- won't make them possible.

IT is one of the few places where process has such a religious ardor to it. Contrast the way many IT pros feel about process with the way scientists feel about the scientific method, for example. Do researchers believe the scientific method GUARANTEES they will be successful at finding a cure for cancer? Heck no. They believe the scientific method will help ensure that whatever they learn through research and experimentation is credible and authentic. But they can still fail, and usually do.

So, where does process really belong? I think it belongs on the sidelines. It should be one of the tools we use to ensure certain aspects of project management are done properly (like tracking finances, billing customers and selecting vendors). It doesn't belong in the driver's seat. It shouldn't show up in a project plan template as defined phases or activities. It won't help you get wherever you are going. Put a smart PERSON in the driver's seat, and let him/her find the way from where you are to where you want to be. It's the only way to get there, because process will never get you there on its own.

This was last published in March 2007

Dig Deeper on Software Development Fundamentals

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close