Discussion on:

Are project management skills valuable?

From Paul's comments I suspect the size and complexity of his projects must be fairly small. If he can develop and keep the project plan in his head as well as the system design the projects are probably one person small projects. Obviously, otherteam members would need to see dome design documentation if there were others involved in the development project.

I suspect his managers are justified in their surprize that he does not do any documentation. Perhaps for job security Paul shouldlearn to document his projects, designs, and results.

I disagree with Butch. Any systems developer worth his salt has done project management in one form or another. It was part of the job and managing resources to meet the deadline which was set. It may not have been the formal PMI process, but it was done. After 30 years in the industry developing systems, I finally decided to formalize my experience and become a PMP. It wasn't hard to do, since it became a way of life.

What is needed here is proper avenues of communication. Producing wads of paper charts and waving them around won't do squat, unless the project manager takes the time to understand the meaning of the charts and enforce responsibility for deadlineson his/her team.

By the same token, someone like Paul who keeps everything in his head risks killing the project when he gets run over by a truck (or fired) tomorrow, as there is no "paper trail" that others can use to pick up the pieces and carry on.

What really is necessary is a team-collaboration tool, something that can get all the team members working on the same page of music, and understanding the needs of one another. "Active! Focus" would be a good example of that. Developers need to know what the stakeholder needs, project managers need to know the impact of changes requested, and reports/charting needs to be available for other members of the organization not directly involved with the project.

While many books and courses have been offered on the topic of the good a project manager can do, rather little (especially directed at the PMs themselves) gets said about the harm they can do. Often management and PMs end up like doctors who have learned that drugs and surgery can make things better but never considered that side effects and blood loss carry risks that ought to be taken very seriously. To carry the medical analogy a little further, they never learned the idea that you should FIRST disagnose the disease THEN decide on the proper treatment. The notion that projects in trouble always need more documentation, more bureaucracy, more people involved, and more planning is as dangerous as it is common. That's not to say that these things are aways bad, in fact sometimes they are exactly what is needed, but too often people get the idea that a single kind of change is always the solution to what ails a sick project or company. PMs should adopt a principle from Hippocrates: First, do no harm.

In some ways, I agree with Paul in that some projects can be accomplished with knowing all the details in his head. But one question I have is how would he do this by implementing a new multinational infrastructure or large web service with an Oracle database backend? If he was doing it himself, he would be correct. But on all large projects, this is not the case.

The second question is if he does it all, how he expects to move on to new projects and positions. He would always be called upon to correct any problems in the new system and has no opportunity to train his replacement so he can move on to bigger and better things.

That's right. Only relatively small projects can get along with such a light amount of administrative work. Small projects with a single person who both knows the details of the problem and implementation is the ideal situation. That's basically what happens in a one man project. If only all projects could be as efficient!

Some problems are just too massive to work that way. It is usually most efficient to either hire someone a little more experienced who can keep it in one-man-land, oradd a second or third senior engineer. What if that's not enough? Then it's often best to have a clear teachnical lead who can specialize in decision-making. This kind of thing usually holds up to about 7 or 8 people. Beyond that there's a HUGE dropoff in productivity. Growing a project team beyond that size is just asking for trouble and should only be done when there's no other choice.

Larger teams often bring serious practical and political hazards. One is that management often thinks that it is OK to insert people who have no idea what is going on. Often this person is called a "project manager". Worse, they often insert such people into a diffuse decision-making process.

If non-technical people are involved in a projct it is best that they be "doing" and not "supervising". There are things that non-technical people can do under the direction of technical leadership: user docs, artwork, testing, and some kinds of documentation. That can help take the load off the technical staff and speed things up. Putting them in charge has in every case I have seen been a wet blanket on the project. Worse, as soon as non-technical people get in charge of things, they usually bring in more non-technical managers to "help". In one case I know of, two technical managers were replaced by 90 non-technical managers to manage a smaller number of engineers and development has all but ground to a halt.

When asked the use of cavalry in battle he replied, "To lend class to what would otherwise be a vulgar brawl" - after 10 years I feel the same - it is a rough job, in transition, everyone has expecations (voiced or otherwise), there are politic thatwould put a Renaissance Prince to shame, you have no authority, scope creep becomes quantums leaps. I give the Noah lecture - Noah was the first project manager and at least the Almighty had the decency to lay out the "requirements" - 60 cubits by 15 cubits by 100 cubits, gopher wood, 2 (or 7 - two vesions in Genesis) of every animal, 40 days because I am going to destroy the earth. The lack of a business owner who participates means death march and public flogging. Try building a 500 site network and no authority to require even one person, to do one thing, at a certain time; because they report to a middle manager who has been "matrixed" into mindlessness and taught that the worse thing in the world is a "decision"! I wax ameobic - the questioner should try the job. I know of an ex-air controller who broke down in the job. Step in the other guy's shoes.

A lot of PMs worry more about the paper work (which has it?s value) & less about what needs to be done. To me running a project is like running a small company we need to find a balance to track info without tons of overhead. Projects fail when the importance of the project, & scope can not be sold, as well as lack of priorities, etc. . Change comes 1 person at a time.

Keeping info in your head & not communicating your thoughts how does your team understand what is going on? The majority of projects fail due to poor communication. This does not mean tons of meetings, tons of e-mail, or tons of phone messages. It simply means at the end of the day the right person has the right info at the right time to make an educated decision that impacts the project (hopefully) in a positive way.

I find that managers overall are clueless dolts that only hinder production. More often than not, they don't understand what they are supposed to be managing, thus they think: Whatever they don't understand must be easy. Lacking the most basic skills both technical and social, and achieving their position by brown-nosing.
In addition they are quick to assign blame but more than willing to take credit which is undeserved.

Wow!! You must really have had some poor managers. Our IT team just lost our manager due to company layoffs. They wanted to keep the people who "actually do the work". Upper management obviously did not have a clue as to what this lady actually did for this department and the company as a whole. She always sang our praises to her bosses, apparently to her own detriment. Lucky for them we are all professionals who know our jobs. However, we are all actively looking for other employment now. A good manager is like gold and many times the people making decisions at the top are too stupid to realize the benefits they bring to the company.

Clearly, some people with the title and/or position of Project Manager really do nothing that adds value to the project. Remember the 'Peter Principle' from the 70s. Real project managers with the proper experiences and skills not only add value to a project, they help make it work correctly, get it done on time and within budget and make sure that it is maintainable once it is in production. The skillset required varies, but includes many of the elements required for continued success of the project. Organization and documentation are often overlooked by 'Peter Priciple' project managers, as are many other skill sets that allow real project managers to assist in getting the job done correctly the first time and within budget. I have been a real project manager for many years and I still have the technical skills to do more than the paperwork involved. Taking failing projects and turning them into successful projects requires a set of skills that is very large. As a consultant,I frequently am asked to get involved after the disaster has occured and to turn it into a success. I have done this many times and each time the disaster aspect could be laid at the feet of a person who held the title, but did not have the proper skills. There are many storys out there about both 'Peter Principle' project managers and their disasters as well as real Project Managers who do know what they are doing and their own skill set allowing the project to succeed.

Its an interesting view, but more of a generalisation about bad managers. In fact project managers wouldn't last very long without social skills. In my experience, influencing and motivating are a major part of the job. The amount of technical skilldepends on the project being undertaken. A PM on a technical project needs sufficient knowledge about what they are doing to make the sensible decisions.

I agree that in a PM role social and communication skills are key to being successfull as well as and understanding of the subject you are managing. Having worked on numerous acquisition projects involving all functions of the business I find that good verbal and communication skills achieve a lot more headway. The PM is there to facilitate and pull together the experts needed on the project and in my opinion should not be hands-on dealing with the technical details.

I partly agree with Paul from the article. I have extensive experience as an engineer and line manager, and I also obtained an Master's degree in Project Management a few years ago, as I viewed that discipline and knowledge essential to delivering larger projects successfully. I have never worked exclusively as a project manager although I have had that responsibility for a number of projects, but I do strongly agree that the process and discipline project management brings to the table is essential to an organization.

I have seen many instances, in organizations both large and small where the process appears to have supplanted the finished product as the deliverable. The problem seems to have been rooted in a number of different causes, but the result is the same. Being enamored with the project management process, or focusing on that process rather than the deliverable should be a trait of the project manager, not the entire team or the sponsor of the project.

I believe itis the role of the sponsor and perhaps other functional management to set some parameters regarding team members exposure to the process, and monitor to what depth the process may or may not need to be ingrained. In a smaller project, I would not expect a project manager to pull out a three-ring binder (metaphor here, most it is now electronic and impose that process structure. I would expect a subset of the process, tailored to the size of the project and the knowledge of the team. The full weight of most formal methodologies should be reserved for the mega-projects.

A couple of questions for Paul come right to mind: How large is your project and how many people will be involved?

For relatively small tasks you certainly can "get away with" doing design and project management in your head to minimize the overhead. But how is your memory for detail over the course of 6 months? How about if 20 people are working on the project; how will everyone work from your vision? How does the customer/client know that you "get it" and how do you schedule?

Net:Cowboy coding and testing can work if the initiative is small enough but for efforts of some magnitude or importance you need project management. You might want to check Steve McConnell's "After the Gold Rush" for some suggestions on how to move towards a software engineering paradigm and see the role that project management should play.

I don't agree with Paul. If his only knows poor project mangers, then I understand his feelings. But let's think about general business management - we all know bad managers but wouldn't dream of eliminating management - or managing our paychecks in our heads! Project management is similar.

I like Tom's reminder that project management is only worth using if it adds value. If you can design a system in your head - without putting it down on paper and without risk to the corporation if you get hit by a bus, then the project value is small and you don't need a project manager. But even with a really small project, project management tools and techniques will make things work better. In this case, many project management techniques are self-evident and an intuitive method of project management may be sufficient.

On larger projects, a more systematic approach to project management is of significant value - but not without business area knowledge.

Tom's comments that he would rather have a skilled project manager with no subject matter experience than a subject matter expert with no project manager experience paints things in black and white and is not helpful. A 'skilled' project manager has learned the business of one or more industries and would have developed an ability to learn any new business. Similarly, a subject matter 'expert' has either gone through one or more projects or has general management experience and can see the value of project management techniques. I would take either willingly.

I don't want a project manager who knows the theory but not the art of project management and has no head for business practices. That is not 'skilled' in my books. Neither do I want a business matter 'expert' who is resistant to change or unfamiliar good business management practices. Either of these results in failure.

A PM is only as successful as his team is, with a team player like Paul no wonder they failed. Building applications in your head, better hope you don't get hit by a bus. As much as an individuals genius can help propel a company, it is the team work that keeps it going. Paul is the oarsman who is out of sync. Lets forget about all the other programs input Pauls way is the only way. Can you imagine NYC with all Madison Ave. all going one way.
A PM does a lot of paperwork(Paul wouldn't understand what that is), facilitates, takes care of cry babies and pulls out his/her hair. They are the first to be blamed when things go wrong, and first to give the credit to the team. They should not be hired to code, install or wash windows. If they are that person needs to buy a clue.

Paul has had a few bad experiences with project managers which he is using to judge project management. In reality this is not at all fair. I would like to take this opportunity to point out the vital importance in not just knowing where you want to be, how to get there but how to apply the methods to the means. Noone can run a successfull project without any knowledge in the area which the project spans.

Somebody please tell me where Paul works!! Clearly there must be an Executive position open, for who in their right mind with Profit and Loss Responsibility would continue to employ Paul and the managers who enable Paul to fritter away precious development dollars? As soon as this company gets a clue and hires a PMP, Paul will be job-hunting at Starbucks.

Enough with the name-calling and blanket generalizations. Not all PM’s are ‘useless dolts’; nor are all programmers arrogant geeks, or all clients clueless idiots.

Project Management is like a toolbox. The tools required will depend on the size, complexity, or priority of the Project being addressed.

The project manager is like a general contractor. He co-ordinates efforts to outlay what the wants, need, abilities, restraints, priorities, scope and risks are. He forms what the critical path is to get there on time, on budget, within scope, while meeting a reasonable level of stakeholder satisfaction.

I don’t want a PM to think he can secure a network, write code, tune a database, do coexistence testing in a lab, advertise, train, provide legal documentation, etc. That is what a team (pulled together by the PM) is for.

The PM utilizes tools that aide in getting budget approvals, regulatory approvals, personnel recruited, RFP and contract negotiation completed, multi-phased development planned, conflict resolution within teams managed, risk assessed/mitigated/avoided, etc. Communication is a vital ability (i.e. Can speak and translate business, IT, Legal, Finance, and Customer talk).
Can the PM do all that in his head? Perhaps, he can even convince the purse string holders, the workers, the clients, the executives, the stakeholders of his abilities and plans. But what happens when a project is put on hold for a year due to budget cuts; or when the PM’s head is not available due to absence; or when documenting PM’s charts, reports and status updates are presented to the shareholders to showcase successes.

Project Management Experience is important, but business and industry experience is priceless. As for subject matter experience - it is so easily out-dated (who needs XML we have cobalt?).

My experience is in the largest Canadian government projects, with some US and international ones. "Head sized" projects can only be of the smallest and least threatening kind. As projects get bigger they get increasingly threatening to the businessviability of the contractor and to the political capital of the government. In my experience, supported by the CHAOS report, the problem of size and complexity is badly managed, not so much by the project management team, but by senior management inboth parties to the endeavour. Unless they obtain a strategic understanding of the project and assign appropriate resources and authority , the project will not be a success. The level of senior management must correlate to the size and threat of the project, and they must demand timely status reporting. I found that even the highest levels of management could readily comprehend a project depicted on a gantt chart of 25 key events - but I suspect that this interface is seldom employed professionally.

That all sounds very nice, but I'll tell you what I see in the real world. 80-90% of PMs have no significant experience in the industry, or if they do it is a list of failures where they killed the projects or the projects were completed despite their contributions rather than because of them. In reality, each additional person involved in a project drags it down by a considerable amount. If the amount of work done by each additional person is not considerable, those additional people actually make the product slower to get out and of worse quality. That's why I see in real world project managers. Do I wish it was different? Sure. But it isn't.

Another key issue most companies seem to get wrong is the vital need for decisions about products to be made by one highly informed individual rather than by a committee of specialists or clueless non-technical people. When I use the word "clueless" I don't mean that as an insult, but as the most apt description for the facts. Many PMs are really nice guys. In fact, they usually get their jobs by being well liked by CEOs and other senior management, but if they are going to make decisions, enforce policies, and explore possibilities (and take the lumps all of these entail) they can't just be following orders or following some kind of recipe book. They need to know what they are doing, and if they don't, they deserve the title "Project Killer", rather than "Project Manager".

Unfortunatrly, many beginning project managers are SME's that are thrown info the fray with minimal training. This often is considered a "promotion" and the PM is now both a new supervisor and a new PM. While this problem is usually a mgt issue, many of those in the trenches also suffer. Mgt take note, everyone cannot succeed at two jobs at once.

First learn to recognize skill set PM brings to table, and if the PM is worth his salt knows how to tailor process to project scope. It not an easy balance, but process is important, perhaps more than experience. Understanding and controlling process insure correct steps are not only completed time, but also repeatable for future projects of similar nature. I have developed numerous plans over years, good number reused by staff on other projects. Getting mileage from initial plan and then later similar projects. Its definitely part of good software engineer toolkit, along with many other things.

Where to begin?
Project Management, as a role, requires different skill sets, knowledge, and talents, depending on the organization establishing / requiring fulfillment of the role. If an organization does not understand itself, what it wants a project to do for it, or what it takes to be successful...anyone given a PM job is in trouble.

Project Management, as a skill, requires an understanding of well-known management principles, appropriate processes, PM tools, etc. This 'knowledge base'can be acquired in a myriad of ways and can even be objectively demonstrated using testing / certification.

Project Management, as a vocation, requires self-examination and understanding, to enable one to both (a) ensure you are doing the kind ofPM work for which you are best suited and (b)successfully determine how to adapt to differing project management environments, success criteria, etc.

To use a 'military metaphor', World War II needed both field Generals like Patton and administrator/diplomats like General Marshall. Patton in Marshall's place would have been a disastor...as would Marshall in Patton's place, trying to lead 3rd Army across France.

The organizational 'wisdom' was knowing that both kinds of 'Project Managers' were going to be needed, hiring / training both kinds, then assigning each where they belonged and were best suited to perform and succeed.

Somebody please tell me where Paul works!! Clearly there must be an Executive position open, for who in their right mind with Profit and Loss Responsibility would continue to employ Paul and the managers who enable Paul to fritter away precious development dollars? As soon as this company gets a clue and hires a PMP, Paul will be job-hunting at Starbucks.

Good project management makes the entire software development process more efficient. This is true for any size project.

I've seen these types of folks many times. They are like the millionaire who made his money in one way and thinks he/she is brilliant at everything else.

On project teams, everyone has a role. In my experience as a techie-guy, as long as everyone does what they are supposed to do, everything gets to production. It sounds like Paul should worry about his own role in a project rather than everyone elses. Additionally, without business justification for a project, Paul should realize thathe is without a job, despite his technical talents.

...Just like there are incompetent project managers, there are incompetent programmers, and, yes, Paul, even incompetent technologists. The world is not perfect, but we can keep it from drivingus to madness during the course of a project by working together. Even with people you may not like or respect. That's part of the job....

Paul isn't a Project Manager, he's a tech leader. Sometimes it's called a team leader, or a project manager, but their function is different than that of a regular PM.

For a lot of IT projects, having a tech leader as a PM is fine: upgrades, basic rollouts, network maintenance, and the like. They are short-term, IT-focused projects.

However, for large-scale projects with significant impact to other depts/groups, all that stupid paperwork and communication is critical to project success. It also provides the ability for others to step in as needed. The last project I managed covered 77 countries, 100K+ users, 27 data centers, in a regulated environment -- there was no way that project could have been successful (or approved by the regulating agencies) without the appropriate supporting documentation and justification.

I've seen too many "project managers" try to manage just by jumping in and "doing the work", and they always say that the other stuff doesn't add value. They are usually the same people who claim that user documentation for applications is a waste of time, as is extensive testing (it either works or it doesn't, right?).

These tools were created for a reason, and the project manager may determinethat it is appropriate to take shortcuts, but to dismiss it as useless is foolish.

It's true that someone needs to be in chagre. The question is whether people who don't actually know what's going on and who are instead (supposedly) experts in organization itself ought to be calling the shots. I can't say I have ever seen that work before, and in fact I can't recall anyone who really understands what's going on having a different opinion.

Let's take this out of the software arena for a moment. Let's say we are organizing a hospital. There's certainly a role for pure managers to do budgeting, handling legal issues, accounting, and so on, but when it comes to treating patients it would be murder to place organization people in charge of a surgery. A lead surgeon of a major surgical team might well end up doing a lot of organization stuff and might even put down the scalpel for good, but he couldn't do a good job of making the decisions without knowing a hell of a lot about details that someone who only knew how to shuffle paper could never have enough perspective on. You tell me, if you were going to have brain surgery would you prefer a team led by a top surgeon or one led by someone who only knew how to push paper? How about a flight crew on a plane? What if you were on the battlefield? Would you rather be led by a great soldier or a great bureaucrat?

You've actually agreed with me -- The person in charge of the surgical unit is often NOT a surgeon. They are the equivalent of a project manager -- they schedule the rooms, ensure that all surgical teams have everything they need for a successful surgery, make sure everything runs smoothly, and if there is an emergency, they look at the schedule and see what can be bumped. They are responsible for communications in both directions (e.g. "you'll have to reschedule b/c an emergency came in" and "there is a new piece of equipment we need"). This allows the surgeons to focus on what they do best.

Project managers often have a lot of real world experience, but doing the actual coding, or surgery, or shooting, isn't their role -- their role is to create an environment that maximizes the potential for success, and tracks progress enough to know when to cut the losses and pull out.

I guess it depends on what you mean by "Manage". Sure, someone needs to keep the lights on, make sure there's paper for the printers, etc. but waht I am getting at is not writing down what is going on (whcih I still maintain can't be done by peoplewho can't understand what is going on), but actually making the hard choices about what to do and how to do it. I have seen purely administrative people (you might call them "secretaries" or "administrative assistants" add value to technical projects, but that's because they are pushing paper that otherwise engineers would have to push. The problem comes when they are put "in charge of the project". That's when they pretty consistently doom their projects.

To use the doctor analogy, if anadministrator told a surgeon to "cut here rather than over here" or "use this tool instead of that one" or "Patient A deserves more of your time than Patient B" (which is the exact equivalent to what "in charge" software managers have to do) you aregoing to have dead bodies on your hands and angry surgeons being at least as outraged as Paul was.

I'm a technical manager, who has done a fair amount of project management for small to mid-sized projects. I agree with Terryn that Paul is confusing the difference between a technical leader and a project manager. I?m sure project size also has something to do with his comments.

I had a fairly competent project manager get laid off, because our company was misusing her as a technical leader. She knew very little about our actual technology, but our company was used to project managers with strong technical skills. Her first couples of projects were a mess, because there was no technical leadership established.

I worked with her and quickly established a good working relationship. I provided technical leadership while she provided project management; by which I mean things like: planning, tracking, checking life-cycle deliverables, sending reminders, compiling reports, etc.

It turned out pretty well for me, since I got to concentrate on the areas I could add value (project design and architecture, design trade-offs, etc.), and not have to worry about the areas that did not excite me (sending out reminders, compiling progress reports). The next couple of projects worked out very well. Unfortunately when the company had to ?down-size?, the early failures overshadowed the more recent successes.

Rather than lashing out agaisnt paul personally (whose own talents and co-workers you don't know) it would be more helpful to address the issues he is raising. Technologists who can't cut the mustard usually get pushed out of projects pretty quickly where I come from. Unfortuantely PMs can usually keep their jobs despite complete incompetence and they often do so by blaming failures on the techies who have less polititical connections and whose work is a lot harder for upper level managers tounderstand.

As for "working together", it isn't possible to "work together" with people whose goals are the implementation of schemes that destroy your work. I'm sure that Paul has had that happen to him many times. So have I. Cooperation withsuch people isn't the road to success, it is the road to sure failure.

By the way, in case yo think I am a dumb techie who doesn't know what he's talking about, for most of the past 10 years what I have been doing is managing projects. The difference is that I am very familiar with the problems that bad PMs (and multiple PMs) cause because I have seen it up close from both sides of the fence.

I recently worked with a (so-called) Project Manager who refused to document anything she did, charged significant overtime with no results to show for it, consistently missed deadlines, failed to provide information, and served as a block to getting anything done. At one point, she actively sabotaged the project. When it came time for a management review of the project, she determined that the project plan was "all messed up" and completely redid it, putting her actual dates in place of the original dates (to make it look as if she made all her deadlines). This was supported by her direct management.

I'm sure this one is going to have a job for a good long time. She is hell to work with, unknowledgable, and hostile to almost everyone. On the up side, she is well-connected politically in the company and threatens a sexual harrassment suit everytime someone tries to remove her or diminish her role.

While I hope that this one is an extreme example, we all know PM's who are every bit as useless and devisive. My point is that a GOOD Project Manager is an asset, not a burden to the project.

I worked in a telecommunications dept as a PM. I was the only one of about 25 that had actually installed telecom equipment. The methods work, but somehow that weird idea that a "PM" could do anything got out there. They have to understand the technology. The purpose of gannt, plans, etc is to communicate. But our country's work culture is task oriented rather results directed. Clarity, ownership, communication - it doesn't matter how - but those are the basics.

Tom Mochal made it quite clear in his article when he wrote "the vast majority of research and information on the subject shows that major work initiatives should be defined, planned, and organized as a project." If you don't invest the time and energy up front in defining your project how can you know if you are hitting the mark? This is where 90% of projects fail. Project definition is useful as a selling and negotiating tool which allows the target customer to opt out or make modifications before serious money has been spent.

Project management skills should be applied far more widely than they are - they work in any environment. Everything is either within a project or process environment or a hybrid of both. There are a lot ofsimilarities in the way they should be planned and managed.

I have taught project management programs to many kinds of people including civil engineers and IT specialists, many of whom were ready to leap onto a piece of software without any real idea of what has to occur before project implementation. The nice thing about PM is that it can really heap to build a team culture. Although everytime I run a monument building exercise in a workshop I have never had the same result twice!

A common difficulty is the tendency to look to project management for large or unusual projects that people have had little or no experience with. It's no wonder they often start to feel a bit edgey about the prospects of success. Neverthelss, one of my favourite sayings about estimating resource requirements is that plus or minus 50% is better than no idea at all.

I have to agree that Paul is a bit of a techno-snob. Been there, said that. Then I got caught managing a "quick bit of work" that smoothly turned into a two year monster (only 26 days to go! Hows that for planning?). Without some serious planningup-front we've been hammered for budget and time and the customers (i.e. the wider business) have been really negative throughout. Sometimes I really don't know why I stuck it out (apart from sheer bloody-mindedness).
If we'd planned we wouldn't have walked into some of the major mistakes that for any other project would have had me out and the project dead. It's only the vital nature and the protection of three VPs with vested interests that have kept this one alive (think: night of the living dead).

The upshot?
Get planning in first. Get reality checking in often - don't worry about Gant charts - just a spreadsheet of milestones is often enough (even for a multi-million Pound project like this one). Get buy in - and then hold them to it. There's nothing more satisfying than having an HR manager praise your work through gritted teeth (because he realises the pile-o-crap he's just had delivered is exactly what he insisted he wanted (against all advice of course!)).
Get commitment, commitment and commitment. Signatures are powerful tools - especially when they get what they asked for.

You cannot do that in your head. You can't even do it in a few documents (the Project Office for this justdoitquickly-from-hell nowturns out at just over 750Mb).

I hate planning - but if I didn't do it I would still be trying to get a hold of the monster. Oh, and the first Gant chart was completed last month. Most of the tools I've seen don't really help unless you are trying to build a house or go to the moon. Software development just doesn't seem to fit with MS Project et al.

What does everyone else think?

I tend to agree with Paul that project management is all about the products and not the process because if you have the desiged product in mind at all times, you will limit the tendency of creating irrelevant processes but be better able to picture the product and apply only those processes that will bring about the actualization of the product.

Project management is balancing deliverables, risk of failure, client expectations, delivery date and cost while influencing people to achieve the goal.

Project managment processes are simply ways of organizing over-whelming amounts of project information for focused thinking and for memorable communication.

The processes won't make a project succeed without trained grey matter to apply themn to achieve the results.

Not having met Paul nor read his entire letter I take a risk in this reply but I do believe from what I did read that Paul has to take at least part of the blame for the Project Managers failures. Admittedly they obviously failed in one of the firsttasks they should have undertaken when putting together their projects. They obviously didn't get buy in from Paul. I am not convinced that this was actually possible to achieve with Paul but regardless of how difficult that was without that fundatmental element having been achieved the projects were 'doomed' from the get go. I would also suggest that Paul, unless he is possessed of a VERY rare skill, could not keep control of any 'project' in his head if it was even monderately complex (200-300 task lines). If he can do that then I suggest that he undertakes a career change and runs projects for large multi-national corporations and charges large sums of money for the service.