Decision Making in Project Management

You should add to #4 of not only the known risks, but also the unknown risks.

How do you write down the unknown risks? The best you can do is to write "there may be some unknown risks". Doesn't really seem worth the time or the ink.

That is always the question.

Being in the OEM (Original Equipment Manufacturer), Unknown unknowns is the most difficult. And is highly depended about experience, (or in project management 'Task experts').

Where you have Contingency budgets for this type of risks built into your plan.

Determining the Dollar and/or Time amount is where your Task Expert helps. And this is basically an educated SWAG

AS far as not being worth the Time and Effort, that depends on the project.

And example, with that attitude, IT projects at one point had 50-70% failure rate. (I can't remember the exact percentage, but it fall in that range)

Point # 5 should be able to give you some of the unknowns. Unless you have a very detailed scope, the most unknown risk you have is your client. With a "team" in place, there should be lots of "what if's" when it comes to the client. There must be someone on the team that has some kind of insight to the client. With any luck, you may have worked for client before and can anticipate what may be upcoming.

"There must be someone on the team that has some kind of insight to the client...."

aka 'Task Specialist'

I was asked to do this the other day. In my case it came down to looking at other systems or departments that could be impacted a few steps up or down the chain.

Facilitating is definitely a tool.

With communications be the prime tool.... speaking of which.....

the formula to calculate the number of communication channels on a project is

N(N-1)/2

N=the number of team members/stakeholders on a project.

That formula assumes a full duplex channel.

Comms has to be 2 way to work effectively. I would remove the division by 2.

Only if your using a radio.

Otherwise, that formula as shown shows the number of paths that is Paths of 2-way communications.

One thing about project management, The Project Management Institute (PMI) created this as a standard (as well as other criteria standards), so it's universally understood.

No, with a radio you can have simplex and even half duplex.

One channel for each direction, with handshaking if required.

That formula accurately counts the number of duplex channels, surely you've used a duplex channel when managing that only seemed to work one way?

Cool Hand Luke quote appropriate here.

I missed the memo.

I'm sure I sent it.

How can you know the unknown? Sensible suggestion, but you can only try to be phsychic, after all, as the man says in #4.

It's something they can only tell you in school,... because they can't teach it, because it can't be explained.

There are different words for it that may help, intuition and experience are a few that comes to mind.

Again, Task Specialists.....

I base it on cost effective. How much do you put in vs how much do you calculate that you will get out and the time for a pay back.

ROI

Its also time, not just ROI. Management wants to see TIME for the ROI. You can project endlessly but it also comes down to safety, getting installation accomplished, training personnel and working out computer interface problems. I have a project that has taken over one year to implement, Its installing a spectrograph at the entrance to the re-heat ovens. The techs will also do a dimensional,ultrasonic and a radiation check. Safety has nearly halted the process as they keep changing their parameters. Yes, i believe in safety but sometimes common sense has to be factored in.

7. $hit or get off the pot - Once the decision has been made IMPLEMENT it. Don't dally about 'second guessing' whether it was the right decision, that's a waste of time. Issue the RFP, RFQ, WCD needed, and get the solution under way.

8. You have to pass it first to find out what inside it.

Full Speed Ahead!

Seriously, the wavering on a decision can really impact the project as a whole.

The decision-making process also varies based on the order of magnitude, the realm of influence of the decision (Product Scope vs. Project Scope), its impact to previously defined and approved deliverables, the engagement level of your Stakeholders (see Salience Model), and your pre-established RACI breakdown.

I find that a good tool to assist in the decision-making process is to define and document a clear set of Operating Principles at project development. Operating Principles establish the framework for decision-making and serve to assist the team in making decisions when questions arise during the course of a project.

I generally separate them into two groups:

1. Project Scope: Principles that impact Project Team performance, interaction, and effectiveness.
2. Product Scope: Principles that impact tangible deliverables.

It's number 2 that, if well documented on the front-end will help answer many questions mid-course. For example:

A principle stating that commonality with existing systems is important may help when a decision between selecting what type of PLC platform will be used... Siemens, AB, GE, etc. arises for a new manufacturing cell. In isolation, maybe Siemens would be the best choice, but if the rest of the facility is AB...

A principle attesting to the importance of proven technology vs. latest technology will impact whether you select the latest/greatest... or if you go tried and true.

A principle attesting the importance of scalability and customization vs. availability of existing inter-organizational tech support would help in the selection of Unix/Linux vs. Windows.

The list of the Operational Principal statements can go on forever, and they will vary for each project. But as you and your team become more experienced Project Managers, you can forecast what a lot of the decision-making needs are going to be, and meet with your Stakeholders in advance to author these Operational Principles that establish the decision-making framework.

Note - The location that these Operating Principles are annotated is within the Project Charter. And remember to keep them high-level and generic. Once you go detailed or specific in an Operating Principle, your 'Scoping' and you don't Scope at the Charter level.

Maybe it's just me, but I wouldn't let your guest author within a mile of any of my projects.

My interpretation of a project is that it has a start position, a goal, a route, budget and time frame to get from one to the other. If he were writing about planning a project or running an enterprise then most of the comments are valid, but the idea of brainstorming for fundamental ideas on how to proceed when part way through a project frightens me rigid. There are also two important failures in the article. How this new decision will impact on decisions made at the outset of the project but not yet implemented or future changes? The decision to install a 32 pair cable to serve 25 sensors is cost effective compared to installing a bus system, until the number of sensors grows to 33. The other is how revokable is this new decision? Substituting a four wire strain gauges for the planned six wire strain gauges to pull back budget over-runs has an impact on the precision of the process, but swapping out to the planned sensors later when the budget allows is relatively straightforward. Installing 300m of 4 core wire instead of 6 core to serve those strain gauges has the same initial impact, but reversing that decision later is a major problem.

What I've seen of what the guest author post, is taken out of a book. Even though some are misinterpreted. These are only tools, each project is different and you have to adjust without being rigid.

Depending on a project, I agree that the fundamentals need to be defined early, yet one may and have come to an impasse on a project midway to where a brain-storming session occurs, wether formally or informally. And anyone that thinks that this ONE post is all about project management is not realistic.

I myself enjoy these light discussions and interactions, either for refresher or just for venting. When there something I don't agree, I'll point out or post like yourself.

Such as in the previous blog: Managing a Project with Difficult Stakeholders

Scope should be in the head line and quality part of the cost and schedule.