Why Thresholds are Important for Project Management

Barry Shore had an interesting post on why it's hard to pull the plug on projects. This caused me to think further about the importance of project thresholds. Threshold evaluations of projects shouldn't be continue/end project decisions, they should be places where the steering committee or project leadership team decides if the project should continue on it's current path or if one of the contingency paths should be followed.

What is a Threshold?
When you have a major project, there should be a few threshold gates (2 to 4) where the steering committee or project leadership team evaluates the progress of the project against predetermined metrics. A decision should be made about whether the project should continue on its current path or if it should go on a different path, a contingent path.

Going into a Threshold Meeting
Unfortunately, often threshold meetings are seen as go/no-go evaluations of a project. Really, they should be evaluations of whether the project is on the correct path currently or if one of the contingent paths or even a new path, is the better way to go.

One of these paths may lead to be project being rapidly ended, but that should not be the only alternative. There should be multiple contingency paths so the leadership can evaluate what is the best route, not whether the project should live.

Have you seen situations where companies have done this? What were your experiences?

What did you think of the Webinar?

I would love to know what you thought of the webinar. If you would like a copy along with the notes, please email me at: ameyer@go2incent.com

Much of the thinking in the different sections is detailed at:

1. Warning Signs

2. Tips to make you more successful at the start

3. When things start going bad

4. When stuck in the tar pits

I would love to know your thoughts. Please make some comments.

Andy

Response to "Freedom is Overrated"

Professor Andrew McAfee has an interesting blog entry Freedom is Overrated in his Harvard Business School blog. In it, he discusses Facebook and Twitter and asks about their uses as business tools. In response to his question, I made several comments from my personal experience . I have found that social networks are used on the fringes of business, not in core businesses. I'll offer an example of the first, reasons for the second and insight into what I think will happen with them.

Use in the Fringes of Business
Please note that my saying "Fringes" is not pejorative, but rather it refers to the outer edges of the network, which is where the really interesting things happen.

One of the great things about FB (Facebook) is that it allows people to create verifiable and yet pseudonymous users. Furthermore, it allows you to create private groups, where only people who are known and invited can participate. Might there not be groups who want to securely blog and discuss events who would find FB useful?

Core Businesses Concerned about Social Tools
Many executives and managers in core businesses are rightfully concerned about the time wasting that accompanies FB and other social tools. There is also a security threat, which is very real. Additionally, there is the bigger issue, that there isn't a clearly defined business problem that social tools solve. Finally, there is the hurdle that many in IT view social networks, SaaS, etc as a threat. This is a valid concern, which, coupled with other issues, will probably keep social tools out of core business applications.

There are business leaders struggling to get blogging and other social/collaborative tools used in corporations. Their struggles are interesting to consider and offer interesting insights that the creators of social tools are not paying as much attention to as they should.

What I Believe will Happen
I do believe these tools will be used, but not in their social sense. They will be used as compliments to other processes (project management, corporate communications etc.) in modified forms. There are people whom I greatly admire who are trying to do this. They are the pioneers developing new, more efficient methods of solving business problems. I look forward to hearing about their successes and insights.

Is Adding Value the Correct Question to Ask about Project Management?

The Project Management Institute (PMI) is trying to prove that project management adds value. Their proof will come as a stunning surprise to no one. Project management is the expense of implementing a project, not the value. If the project is worthwhile, the project is worth the expense. At its best, good project management will minimize the expense.

Why Does Someone Start a Project?
People don't usually start projects for the joy of doing the project, they do it because they want the value that the project adds. For example, someone wants a bridge over the river, so they go through the process of planning and constructing the bridge. Does the construction add value? No, its the bridge that adds value, the construction is the expense of having the bridge.

When someone decides to implement an ERP system, they are not doing it for the pleasure of examining their processes, changing them and implementing them through some new piece of software. They do it because they want to plan their enterprise resources. The project management and the project are the expense of doing that.

What is the Correct Question?
Someone may ask if there is enough value in the bridge or in having their resources planned? These are excellent questions, which in many cases should be closely scrutinized before beginning a project. However, once the decision has been made to execute the project, project management is the expense of executing the project.

An expense is an expense, how can it have an ROI?

Why Change is so Difficult

Peter Vajda has an excellent post on Why People Resist Change. While I have a lot of respect for Peter, I think his argument misses some important facts. Namely the fact that people resist change because they can't see how it benefits them. In fact, often times the changes will hurt them. In those situations, no amount of involving them in the decision making process is going to persuade them to execute the decision.

Very briefly, Peter's thesis is that people resist change because they are not involved in the decision to change. While his arguments are compelling, they don't address the core reason why people resist change.

Why People Resist Change
When someone is trying to change a structure or process, by definition there is a structure and process which already exists. It's a good bet that someone put it in place because it benefits them, intentionally or accidental. In either case, they are probably the key power brokers necessary to make the new processes work. The new processes are often more efficient because they get rid of the loopholes that the power brokers currently exploit.

Everyone will often agree that the new structures and processes benefit the company as a whole. However, it's a good bet that they will not benefit the people who are benefiting today. And its a better bet, that even if those people agree in principle, when it comes to executing them, they will resist. They may resist passively or subversively, but they will resist. And it's good bet that they'll be smart enough to do it quietly.

Think of it this way. If your mother suggested changing from eating spinach to eating cake, it's quite likely that you'd implement that change easily. However, if she suggested changing your desert from cake to spinach, no matter how much healthier the diet would be, you're likely to resist. Do you really think being involved in the decision making process would change your outlook?

Why is Value so Difficult to Measure in Project Management?

People struggle quantifying the value of project management. Partly because people value the outcome not the process. When you go to a restaurant for dinner, you care about the dinner not the process by which it was made. Part of it is also the new projects are difficult. Making dinner is a known, repeated process. Implementing a large new application in your company hasn't been done before. That makes it difficult.

Change is difficult and no matter what anyone says about their experience, they've never made changes in your company before. I believe the measure of this difficulty was described a long time ago:

"There is nothing more difficult to take in hand, more doubtful in its success, more dangerous in its execution, than to take the lead in the introduction of a new order of things. The innovator makes enemies of all those who prospered under the old order, and only lukewarm support is forthcoming from those who would prosper under the new. Their support is lukewarm partly from fear of their adversaries, who have the existing laws on their side, and partly because men are generally incredulous, never really trusting new things unless they have tested them by experience.” - Machiavelli

Its easy to forget that people have struggled making changes for a very long time. New technologies don't change that. Machiavelli wrote this in about 1515. Maybe things haven't really changed all that much in the last 500 or so years.

Is PMI Focusing on the Right Things?

Dr. Janice Thomas and Mark Mullaly announced the findings of a 4 year study that included case studies from 65 companies looking at the value of project management. All credit to them for trying to rationalize and draw meaning from such diverse groups. The question is, should they try to?

What is Project Management?
According to the PMBOK guide, "Project Management is accomplished through the application and integration of the project management processes of initiating, planning, executing, monitoring and controlling and closing."

Whether constructing a building, making dinner or developing software; there are processes that will help one be more successful. At its core, that is project management.

Different Industries are Different
Is the process for constructing a building the same as the process for making dinner? Is it even similar to the process for developing software? No, the processes must be different. Are the skill sets required to succeed at each step similar? No, safety concerns in construction are obviously different from cleanliness concerns in cooking or complier concerns in software.

Can the Processes in One Make you Better in Another?
The roots of project management probably come from construction. The Romans realized foundations were needed before building walls and roofs. Specialized skills and the coordination between them are as appearant in the Roman Coliseum as in a modern sky scrappers.

At a very generic level, the ideas of critical paths, deadlines and dependencies may cross industries, but do the specialized skills to be successful in each area align? No. Safety concerns in construction are paramount. Cranes falling in Houston are catastrophic to that project, but not a concern to someone running a restaurant. Cleanliness hopefully is an overriding concern to the restaurant owner, but unfortunately isn't so critical to software developers. [Editor: Are you criticizing developers? Talk about biting the hand the feeds you...]

Comparisons between Industries are not so Meaningful
While processes may have underlying similarities, the specialized skills required to make each step in the process successful are so different, comparisons between industries are not so meaningful and not where PMI should be focusing.

What do you think?

Are Project Managers Marooned on an Island?

Projects often pull people from different departments together to work on a project. While that is what the project requires to be successful, what does that mean for the people pulled from the different departments? Is the project of primary importance to them or is what's happening in their department of primary importance?

Business in Silos
When the modern corporation was formed, different departments were organized around specific functions. Accounting, Marketing, Sales, Finance, Operations and even IT all had separate requirements, required different skills and had different, recognizable paths for promotion. These departments offered structure, communications channels and common ground which was the basis for understanding.

Project management for larger projects, doesn't fit in any of those silos [Editor: we prefer the word department, thank you.] For a large project, people are drawn from across the organization, often temporarily, to work on that one project. Where is the common ground or structure?

Is PM unique?
PM often is unique, especially in organizations that are not focused around doing projects. Not only must the team get from NY to LA, but often times they have to invent the car, build the roads and put in the gas stations.

Not only does the team have to get from NY to LA, they have to go through the four stages of team development (Forming – Storming – Norming – Performing), usually very quickly.

What happens after the project?
All of this is very interesting, the question of whether project managers are on an island, but for someone with promotion aspirations, what is the next step after being a PM?

What have you seen?

Does PMI (Project Management Institute) find value in Project Management?

On July 15, PMI presented the finding of their four year, $3M study looking to see if project management added value. You can see their presentation here: PMI Presentation

Their results reminded me of Churchill's quote about democracy:

Democracy is the worst form of government except all those other forms that have been tried. — Winston Churchill

PM is messy, imperfect and immature, but what are the alternatives? I give Dr. Janice Thomas and Mr Mark Mullaly credit for presenting as objective of a report as they could. PMI gave them a lot of money to say that PM adds value. Reality is messy and that is really what their study found.

Consider that they looked at 65 companies in different industries, countries and organization structures. They looked at private, public, government and sole proprietorships. What insights do government findings offer to sole proprietorships? Equally, PM in office construction bears little resemblance to PM in software development. They also found that culture and context in China bear much resemblance to that in the US. All of these affect outcomes.

To me, what they did was the equivalent of asking 65 different groups of people who grow vegetables to comment on the value of water and fertilizer. I'm not sure what conclusions you could draw looking at my mother's tomato plants in Wisconsin, hog farms in Canada or government farming cooperatives in China.

I'll save researchers $3M and emphatically state that the empirical evidence shows that fertilizer is valuable.

That's pretty much what I think PMI found. Any thoughts?

Importance of Project Sponsors

I was talking to a friend of mine about what hurts projects, and he reminded me of how important project sponsors are. Ideally, the sponsor has a stake, is invested in making the project succeed and has the time to dedicate to the project that they can at least understand intuitively what is happening and represent it to the rest of the company.

Ideal Sponsor
Understands the business purpose, knows the main business people necessary to make the project succeed, dedicates the time to understand intuitively what is happening on the project and has a personal stake in making the project succeed.

Showcase Sponsor
This is a sponsor who is very highly ranked in the company, maybe the CIO or even CEO. Be careful of these types of sponsors. It's gratifying to be working with people at the top of the house, but in all likelihood, they don't have much time to dedicate to the project. Be very careful if you can't secure time every week with your sponsor.

"I want to be more important" Sponsor
A sponsor needs to have enough clout in the company that they can break down walls and solve problems. It doesn't help if they have to go to their boss to solve the problem, they need to solve it themselves. If the company has a steering committee, they need to sit on the steering committee. Be careful if your sponsor has bitten off more than they can chew.

The "always on a plane" sponsor
There are some sponsors who really do want to help, but somehow they are never around. Phone calls, IM's, skype and all the rest are nice, but it's even better if you can talk to your sponsor face to face. They are your partner making the project work.

The Lone Wolf
Be very careful if you are working for someone who tries to limit your access to the rest of the organization or who wants to develop the project in secret. In some cases this is necessary and beneficial, but in other cases, the person can be going off on their own little adventure and if they lose the support of the organization, it can all come tumbling down fast!

Are there other types of sponsors you've worked with?

Personal Project Planning

Have you ever interviewed someone for a project management position and heard them rattle on how great they think PM is? How it makes everything better? Everything more organized?

Here's a question to ask them. If they're married, did they put together a project plan and schedule for their wedding? If their single, dating works just as well, but the wedding a beautiful example.

If people are so enthusiastic about PM, why don't they use it in their private lives? A wedding would be the perfect situation. There are a large number of people, many things to be taken care of, a deadline, dependencies etc. Custom made for project planning.

Except, I've never had a single person who did it. If it's good for work, why don't people use it personally? If they don't use PM personally, how committed to it can they be at work?

Things that make you go, hummmmm

Celebrating Victories on Projects

Be faithful in small things because it is in them that your strength lies. - Mother Teresa

Projects, deliverables, tasks and success are made up of little things. If people working on projects are going to care about little things, the people running projects better care about the little things. Many of them are too small to mention outside the team. That's fine. In fact, that's great. All success will begin with the team. Whether a project is just kicking off, maturing after the novelty has worn off or is stuck in the tar pits, as a project manager, you strength lays in the little things.

Recognize people for accomplishing them. Celebrate them. It doesn't have to be huge, but acknowledging the little victories will go along way.

Maybe there is some piece of data which the team needed to get access to, some GUI which needs to be built, some interface completed etc. They may be tasks, sub-tasks or just important work elements. The important thing is that there needs to be realization and celebration of progress that is being made. To keep morale up, people must see that progress is being made and that there is an end in sight, whether its success or the project being ended.

There are many ways to do this, email, blogs, discussions, team meetings are all good. There is one other way that I found very successful. Marking a bottle was also very useful.

Marking a bottle really works if everyone is in the same office. The way we did it, was to use a bottle of reasonably sweat liquor (Bacardi Limon was our choice). Whenever there was some success, we noted that success on a post-it note, put the initials of everyone involved and present and then poured each of them a shot. The post it note was then taped to the bottle so that the bottle was marketed with successes as the project went along. Similar things could be done with notes and pictures on a wall or web-page. At the point of the project we were on, we needed alcohol. Hopefully you don’t reach that same point.

When the project is in the tar pits or at any other time, remember and take advantage of the steps that are available to you.

1. Identify how the project can be killed if necessary and admit that it is possible.
2. Refine the scope so that nice to haves are on a “Not right now” list and critical items are the main focus.
3. Make sure the communication channels between the project sponsor and PM and clear, with the team and with the organization are known.
4. Celebrate victories that move the team forward.

Steps to Take When Your Project is in the Tar Pits

When times are good you can study things for a while, going over every pro and con. But when you’re in a crisis, there’s no time to run a study. You’ve got to put down on a piece of paper the ten things that you absolutely have to do. That’s what you concentrate on. Everything else – forget it. The specter of dying has a way of focusing your attention in a big hurry.
- Lee Iacocca

When a project is mired in the tar pits, there are benefits and there are issues and threats. To successfully get out of the tar pits requires a clear understanding of the projects direction, the realization of where one is getting traction and most important: team morale. Know and align people’s motivations with these goals to succeed. How do you do this?

While it might seem counter-intuitive, a smart project manager working with their sponsor will set a project kill line. This has several major advantages.

1. If there are silent assassins who want to kill the project, it gives them an effective and efficient way to do so. If you don’t know who they are, it might also provide a way to find out.
2. It minimizes the effects of the endless death-march.
3. It clarifies what is important from what is nice to have.
   

This last point cannot be underestimated. Many projects complain of scope creep, or what one confidant called “WIMBY – Wanted In My Back Yard”. As projects go along, many times people will try to get requirements added that benefit them or will make their lives easier. Some of this is simply the horse-trading necessary to move any project forward.

When a project gets stuck in the tar-pits, it is an ideal time to refocus and shrink the scope to what is really critical. Think about making a “Not right now” list. In this way, ideas and requirements which were collected as the project goes along are not lost, the people who submitted them are not forgotten and you’ve built a valuable list when you come to justify future projects. You and you sponsor will understand these requirements and the people who entered them better than anyone else.

Communicate what is happening to the people who entered the requirements. These people are now motivated to be supporters of your continued efforts on the project and should be turned into supporters of future projects.

Seeing if these people enlist and support your current, refocused project with an eye toward future projects will go along way towards learning who your real supporters are, who is apathetic and who your silent assassins may be. Don’t lose this opportunity, it is critical to take advantage of this and learn where people really stand in a crisis.

Clarify communications. There are three levels of communication which need to be understood.

1. Project Sponsor – PM Communications
2. Team Communications
3. Organizational Communications
   

Project Sponsor – PM Communications
When things are in the tar pits is when you really prove yourself and learn how the project sponsor reacts and will react in the future. Make sure you understand how to best communicate with the project sponsor prior to problems and discover how they react faced with adversity. It is out of this relationship that success or failure will originate. Make sure you know the patterns of communication and become attuned to when, if and why they change. Investigate changes.

Team Communications
How you communicate with the project team in the face of a crisis will go a long way towards determining success. To succeed, people must have a clear idea of what is required to succeed. A crisis has a wonderful way of clarifying what is crucial. Make sure that what is being clarified is actually what is crucial. It is also crucial that people’s morale doesn’t get crushed.

Determining what is crucial is done between the project sponsor and PM. The team needs to be involved in this and feel that they have input. They should also have input into what goes on the “Not right now” list. It’s important that the team is a part of what’s happening. It’s also important to maintain morale.

To avoid this, celebrate victories. That will be the topic of my next post.

How to React When Things Start Going Bad on a Project

Machiavelli: “As the doctors say of a wasting disease, to start with it is easy to cure but difficult to diagnose; after a time, unless it has been diagnosed and treated at the outset, it becomes easy to diagnose but difficult to cure.”

Diagnosing problems early is the goal. If you can and apply corrective measures, issues are resolved or effectively managed. How do you identify risks? Other than that dull sinking feeling in your gut. Use your judgment and communications skills.

Ideally you have risk registers or have at least done enough risk analysis to be open to recognizing risks or when something is different. Lacking the formal elements isn’t a problem if the structures that identify risks (known or unknown) make it much easier to know when an issue starts and if it has the potential to pull the project into the tar pits.

Knowing that something is becoming an issue is the first step. Next find the root cause. This is critical because you want to address the root cause, not the symptom. How do you find the root cause?

Try thinking about it as similar to clicking down into hyper links in a web page. Rather than just talking like you're just reading along on a page, which is how most conversations go, click down to discover the deeper meanings.

Let me explain what I mean. Most conversations take place at the surface level. “Hi, how are you? Wasn’t the weather great over the weekend? Who do you think is going to win the game on Sunday? Did you get the report? etc. etc. etc.”

This conversation takes place entirely at the surface level. People talk without clicking down to the deeper level to look for meaning. To do so, think about asking reflective questions as a way to click down to the root cause. Reflective questions take the key idea from a statement and reflect it back as a question looking for more information about that area.

For example:

• Developer: “We have a problem on the deliverable.”
• Project Manager: “What is the problem?”
• Dev: “The interface isn’t working”
• PM: “What’s not working about the interface?”
• Dev: “We can’t get what we need.”
• PM: “What do you need?”
• Dev: “The data we need isn’t there.”
• PM: “What data is that?”
• Dev: “The shipping notice information isn't available out of the ERP system in a way we can access it consistently.”

The example is greatly simplified, but it shows how reflectively asking questions helps you click down to identify root causes. The symptom is that there is a problem with the deliverable; the root cause is that the data can’t be accessed consistently through the interface.

If you identify the root causes, you can judge if there are issues to be managed or if those issues may grow into threats to the project. It is this judgment which differentiates great project managers from the competent.

Judgment is what you want to develop. Judgment can’t be measured or taught, it can only be learned. It’s a little like the abdominal snowman. You’ll see the footprints, but never the snowman.

You learn judgment through experience, making mistakes and learning. There are a couple of things to think about when you’re judging an issue:

• Can it be addressed without affecting the critical path?
• Will it significantly affect the project buffers?
• What will the impact be?
• How can I tell if it’s getting worse?

Use your judgment – it will help you learn and address issues early and effectively.

Tips for Project Management Success

“There is nothing more difficult to take in hand, more doubtful in its success, more dangerous in its execution, than to take the lead in the introduction of a new order of things. The innovator makes enemies of all those who prospered under the old order, and only lukewarm support is forthcoming from those who would prosper under the new. Their support is lukewarm partly from fear of their adversaries, who have the existing laws on their side, and partly because men are generally incredulous, never really trusting new things unless they have tested them by experience.”

- Machiavelli

There are many things which will determine success or failure on a project. The biggest, by far, is the relationship the project manager has with the project sponsor. Out of that relationship will come the strategies, tactics, communication and vision of what the project will be and how it will operate in the organization.

There are a couple things to keep in mind with this relationship.

1. Form matters. Who says what, when is it said, how is it said, who is it said to by whom all matter. The bigger and more political the project, the more important this is.
2. The sponsor – pm relationship will matter more than anything else in determining project success or failure.
3. Look for patterns and be alert for any changes.

Make sure you know who your sponsor is. There is only one. This is the person who controls the budget and succeeds or fails based upon the success or failure of the project. While you may not spend the majority of your time with this person, a lot of your thinking will be focused around this person and communicating with this person.

There are some things to understand.

a) What is the person’s standing in the organization?

b) Is the sponsor writing checks that they can’t cash? The sponsor must have the direct strength to make a project work. If they are not strong enough, when push comes to shove, they will be run over. If they must depend upon someone else’s strength, the project has a huge risk.

c) Relatively, is the sponsor rising or falling? This will change through the life of the project. That will be critical to how what and when you communicate things on the project.

d) The sponsor must always know the truth. There may be reasons that something other than “the truth, the whole truth and nothing but the truth” may be communicated at particular times, but that person’s footing must always be solid. No one else can know more about the project than they do.

e) Understand and develop a pattern for how this relationship works and how communications are handled. Be extremely sensitive to changes in that pattern. Be extremely sensitive to changes in the organization which effect that person’s relative position.

f) How does the sponsor relate and maneuver people in the organization? Figure this out early and pay attention to whether it changes.

Respect the sponsor’s time. If you see any changes, investigate it early.

The most important thing to establish: How do you want me to let you know if there are problems?

Warning signs of trouble on a project

Is there a way of predicting which projects will have problems?

Sun Tzu reminds us: "Every battle is won or lost before it's ever fought." The same is true with projects. So what should one look for to see if the battle will be won or lost? Here are nine questions to ask:

1. Are we trying to put stretch pants on a rhino?
2. Am I working for a lone wolf?
3. Is there a silent assassin?
4. Has a "can't fail" mentality developed around the project?
   
5. Is there a let's just get started and plan later attitude?
   
6. Is there a threshold to determine if we go on?
   
7. Are processes followed?
8. Is there a focus on deliverables and budget, but no thought about technology?
9. Has the company ever done a project like this before?

Are we trying to put stretch pants on a rhino?
I'm serious about this. There are many times that in order to sell a project in a company, managers promise everything to everybody. They will do whatever pet idea is necessary to get someone to approve the project. They try and stretch the project to appease everyone. Have you seen this?

The problem is, like stretch pants on a rhino, it will work for awhile, but as soon as the rhino sits down, or runs or engages in some type of bodily relief, it's going to get ugly. The fabric will rip and mending it could be temporary and painful. Especially if the needle pokes the rhino, it could get ugly.

Be wary of stretch the project to cover the rhino.

Am I working for a lone wolf?
Are you working for one person? Do they say, "Ask me any questions." or "Don't bother other's with what we're doing." or "We need to get this working before we involve too many other people."

This can be a good approach if the project has a short enough duration, but if the project exists entirely at the whim of one person, watch out if that persons focus or status changes.

Beware if you're working for a lone wolf.

Is there a silent assassin?
Often times there will be people who don't want the project to succeed. There may be many reasons for this and you should try to discover them, but the first thing to find out is: "Who wants this to succeed and who doesn't?"

Silent assassins are particularly dangerous because you don't know who they are and so you can't know how to deal with them. If you're lucky, they're public about their opposition. Then you know what you're up against.

Rather than agonizing yourself about silent assassins' motivations, take a different approach. While it might seem counter intuitive, announcing a threshold or gate level that the project must exceed to continue gives the silent assassin a way to kill a project if they are strong enough. If they are not strong enough to keep the project from meeting this threshold, getting over the threshold or through the gate will build more public support.

The point is, if the assassin knows how to kill the project, they have to decide if they are strong enough and determined enough to do so. What you want to be careful of is letting someone nick and cut you to death without your knowing where it's coming from.

Has a "can't fail" mentality developed around the project?
The problem is that, if a project takes on a "can't fail" approach, it almost guarantees failure. It puts too much pressure on the project team and prevents clear thinking and communications.

Set up gates and threshold points where a project is objectively reviewed and there is a real possibility that the project can be killed. This focuses people and prevents a "can't fail" mentality from developing.

Is there a let's just get started and plan later attitude?
It's been said a thousand times: "If you fail to plan, you're planning to fail." Unfortunately, too often, one spends immense amounts of time and energy "selling" a project inside a company. When the project eventually gets approved, people are so quick to want to show progress and justify the project, that planning gets lost.

Don't give into temptation and remember to plan the project, work the plan and evaluate the plan as you're going along.

Is there a threshold to determine if we go on?
Thresholds are your friend. How do you know if something is successful? You know if it meets the goals that enable it to cross the threshold.

How do you prevent people adding every dream and wish they ever had into your project? Having a threshold defines what you have to do to continue the project AND it defines what you cannot spend time on. Thresholds focus attention, giving people on the project something to shoot for and a reason to celebrate when its achieved.

One of the biggest mistakes a project manager can make is never celebrating success. Thresholds provide the target, the yard marker and the reason to pat people on the back and celebrate success. Use them, they are your friend.

Are processes followed?
Have you ever been in a company where there are no processes? It's like trying to push a river upstream. Have you been in a company that has processes, but they're not followed? Or even worse, they're used as method to kill something that got approved but no one wants to do. Put it into an endless process.

Look around and see if there are processes by which things get done at a company compared to if things get accomplished through heroic effort. Whether it's ordering supplies, doing employee reviews or executing projects; a company either follows processes or it doesn't follow processes.

If it doesn't follow processes, know what you're getting into. Before you start the project, you'll have to define the processes necessary for the project to succeed, train people on them and then make them work. It can be very rewarding, but know what you're getting yourself into.

Is there a focus on deliverables and budget, but no thought about technology?
Many times businesses will know what the deliverables are that they want and they'll think about the time it will take, but they won't know about what it will take technically to get there. Even worse, they'll listen to a salesman from a software or consulting company sweet talk them into thinking that it'll be so easy with their technology or methodology.

But it's still work and it adds another layer of complexity which is rarely accounted for. When looking at a project, think about how much of the technology that is being used is new to the organization. Having consultants and contractors who know the stuff is nice, having employees who know how something works is even better.

Ignorance with new technologies is not bliss, it's a devil you know nothing about that is waiting to torture your life.

Has the company ever done a project like this before?
Actually, the question could be better thought of as, has anyone working on the project ever done anything like this before? If the company has experience doing these types of projects, then they know what to expect. If people on the project, working for the company have experience, then they are battle tested and know where many of the snakes are lurking in the grass.

You wouldn't feel comfortable having your house built by people who had never built a house before. Be just as concerned about executing a project with people who have never done a project like this before.

These are some of the warning signs to look for when you're considering going onto a project. Are there other signs you've seen?

Inquiring minds want to know...