Project Management – Getting Started

I realize that you became aware of project management from programming but it is not just software development. Projects happen in all engineering and business realms. What you've inferred but not stated is that a project is finite. A project will have a start and most notably an end. As such your project team will eventually be disbanded when the project is completed.

From the beginning it is therefore good to define who will be handed the operations of the completed project. Will this be your customer, another division of your company or will some of your team now "switch hats" to become operators. It is necessary to identify who will operate the completed project because they will be pivotal in defining the goals of the project. While some projects will be operated by known, named, specific individuals (Brenda's wedding, custom vehicle fabrication, etc.) most of the time in engineering projects this will not be true. So a proxy for the operator/customer should exist early in the project development. Steve Jobs was masterful at being the proxy for Apple's customer base. The "ease of use" designed into many Apple products shows an understanding of the operator.

One reason software project are mentioned prominently is the effects across the board.... In all disciplines.

One thing that I have surprisingly found is that over 80% of it projects fail.

I have been brought into a large number of these. Which is a tough thing to do, when your scope creep went unmangaged, your delievables are not proforming and especially when there is no exit plan to kill the project. And you have to develop acceptable alternatives with very limited resources.

http://www.hks.harvard.edu/m-rcbg/ethiopia/Publications/Top%2010%20Reasons%20Why%20Systems%20Projects%20Fail.pdf

These are some great points to supplement the blog post. Things often fall apart at the end because nobody formally closes out the project. This can leave a lot of details unchecked. If these details go unfixed it can cause problems in the future. It's also important to celebrate the achievements of a project after its completion.

I also wanted to add that I do not have a background in programming. I've spent more than 5 years using lean manufacturing concepts to improve processes and operations in the department where I work. Some of these required programming but most required eliminating wasteful, repetitive steps. One notable project did require a small amount of programming to fix a data gathering process that wound up being about a 90% time savings. Most of my knowledge is based on lean concepts rather than another method. I tried to use varied examples in the post.

There are still individuals who believe that all one has to do is to print-out a Gantt Chart and give it to everyone, and everything will be fine. The facts are different: as a Project Manager, if one isn't doing something, then something is going wrong; a Gantt Chart is out of date and pretty useless the moment it is printed.

A project is always fluid, a gannet is only a tool, and one of many.

MSProject as an example is a great tool. But every project is different, and one needs to use the correct tools needed.

Exactly. That's why a print-out is not worth the paper it is printed upon.

just reenforcing your statement. and just a correction on my earlier post, thats gantt not gannet ....

I do not agree. If the pipe fitters have overrun in phases 1,2 & 3 it is a fairly good bet that they will overrun in phases 4 & 5 unless you make changes. Only by looking at historic data can you see if the overruns are caused by the cable pullers working in the same area at the same time with the two groups impeding each others progress. Looking at how you arrived at the current point in the project can allow you to make adjustments to eliminate further bottlenecks. A printout is easy to produce and is useful in communicating what changes are needed and why.

Gnatt charts going forward predict what you want to happen, rather than what is going to happen. Gnatt charts showing the difference between what you planned and what actually happened in the past are a useful tool.

A gantt is only a tool. one of many. The only time a gantt value is questioned is when its not up to date. With projects being fluid, this can be an ungoing work for just a person/team.

I worked on a projects in excise $100 million, and the gantt ^{(The gantt chart printed out was on a 36" by about 240" with fine print)} was always out dated. which brings in another very important tool. Communication.

I don't think one can single out one item, especially when each tool in project management is comprised of several different components or tools.

ps, that progect with a gantt chart, that was actually a program......which Program Management is slightly different, by which is made up of projects.

What do you think is the most important factor to consider in project planning?

Upper management commitment.

I've seen too many projects fail because end users/recipients don't buy in for various reasons and upper management turns a blind eye.

The reasons for not buying in are usually specious or self-serving and ignore the higher level benefit or value to the company or organization as a whole.

There must be a commitment by a level of authority above the scope of the project. I have refused participation in projects where that commitment is not strong.

Hooker

your comment:

I have refused participation in projects where that commitment is not strong.

is interesting, that should be looked at.

^{One thing I do hate is the slang or key words that are used in project management. But I have to use it.}

Change is very hard to do in a organization, especially if it has to do with the 'culture' of the company.

But when change is for the 'Overall Best' there has to be 'Champions" to carry out these changes. Is it difficult, damn right it is, and it's not for the non-committed. If I'm not committed to the change, I'll speak my mind and give my position as well as challenge the 'change'. It has to be presented in a way that convinces me that this change is for the overall best.

Otherwise, if not committed, it is wise not to be on the team. And by doing so takes leadership in itself............. though, it may have consequences on your future, but if your convictions are strong and consistant, you'll realize that before anyone else.

Perhaps "refused" was a little strong. Avoided might've been better.

And, INDEED, culture (and the attendant politics) is often a major obstacle. And that can usually only be altered by management at the highest level(s).

I've never attempted a project that was not justified by a significant ROI. Anything less is a waste of management time. I have, however, had managers/dept heads attempt to scuttle a project simply because it would require operational changes in their departments. And, because the project end result didn't directly benefit their own bottom line, they would actively lobby to stop the project.

In these cases, it almost always comes down to political will and manipulation.

Hooker

I took the word 'refuse' quite negatively at first, but when I reread your post, I saw the meaning you were trying to convey. and had to agree with it.....

^{I myself used words that had an edge to it and to the light of heart and had to re-phase.}

And your comment of "political will and manipulation" is/can be pretty rampant.

My first job out of college, I had somehow been positioned to be in on the steering committee of the department. Some of the views did not sit well with me at all, but because of the time constraints, pressure, ect..... we all compromised. And after everything was implemented, we all agreed the actual compromise was the best way of going about it. and if decisions that were made weighed more to one side or the other, it may have been satisfactory...... but would not been the best results with the same resource inputs. We all complimented with strengths to the others weaknesses

That experience made me realize no one person has all the right answers, especially Number one, with that being me.......... very humbling.

But once approved, no wishy-washing response...... you own it, and you implement it.

"What do you think is the most important factor to consider in project planning?"

That everybody involved understands the milestones and goals.

Too often there are disconnects between expectations and deliverables. Often people only focus upon their own part of the project and ignore the rest. Often the Project Manager does not have enough business and technical experience to understand and manage both sides of the project adequately. Unrealistic schedules and performance expectations are set, often unwittingly. If you didn't realize that you set an impractical milestone or goal then you'll probably not notice until it bites you. Also, everybody involved has to take those milestones and goals seriously. When they don't, you get scope creep and delays and budget busting.

This is an engineering forum so I'm going to make a few points to that audience. Yes the technical aspects of a project are important because if you fail to meet performance objectives then the project fails. But the business aspects (that you may not have been trained to understand nor care about) are just as vital, lest the company folds and you lose your job. So it's better to check your ego at the door. Project Managers who come out of the technical side potentially make good project leaders, but only if they've been trained on the business side of things. Just because one is a good technician does not mean one will be a good manager, but many companies assume that and throw one into Project Management without adequate preparation. If you find yourself thrust into that position, demand tools and training to head off a potential train wreck.