TO OUR FINANCE PROFESSOR
Dear Keith: Thank you for a course well done.

Students will learn many things in a course but realistically, only several things will be remembered with the passage of time. One of an instructor’s goals therefore should be to facilitate that.

An instructor must make a decision concerning his teaching philosophy. Should he try to teach them everything or should he teach them only enough? The answer makes a significant difference.

The first approach, in my opinion, is full of complications. How can one reasonably expect to teach students everything, even when the topics are defined by a set of Terminal Course Objectives (TCOs)? Consider the students’ attitude. Many of them probably enrolled in the class because it was necessary and not because the subject interested them. This approach has a tendency to lead an instructor who believes that these TCOs are set in stone to evaluate the performance of his students against his personal standard. An instructor, by definition, is a master of his subject. Consequently, everything that he teaches, he knows very well. That poses a dilemma, whether the instructor realizes it or not. How can a student, no matter how diligent, understand much less master, the nuances and aspects of each TCO? I contend that this approach creates a hurdle so high that students will not be able to measure up. Every nuance of each TCO counts. Every time that mastery of each nuance is not demonstrated, it counts against the student.

TCOs should serve as a guide, I think. A prudent instructor, in my mind, will use the TCOs in a flexible manner. He could, for instance, at the start of the course, survey the students in order to learn their academic objective. Someone pursuing an MBA with a concentration in Project Management would have a different perspective than someone pursuing a Master’s degree in Project Management. A survey will give the instructor more insight into the needs of his students. This might sound absurd but like anything else, instructional style can be dogmatic. To dogma I contend that one size will not fit all. Address the needs of the customer and realize that the customer is your student.

Focus on the essentials. Follow the Pareto rule. Twenty percent of what you teach will account for 80% of what is important. Might it not be wiser to focus on that 20% then? The challenge in fact is determining the content of that 20%. This is where your expertise and experience as a subject matter expert will help you.

Your method was certainly different but I think you exhibited an uncommon touch in focusing on that 20%. Thanks to this course I am more cognizant of the importance and operation of the finance side of the house.

Within the healthcare sector, my field, hospitals are a key institutional player. Since the 1990s their environment has become more competitive. Looking back I now realize that there are still plenty of managers who don’t appreciate why creditworthiness, for instance, matters. Creditworthy organizations, as you taught, enjoy improved capital market opportunities. A higher credit rating means lower interest costs. A small decrease in the capital rate will, over the life of a bond, translate into significant savings. Creditworthy hospitals also enjoy less restrictive covenants that, in turn, extend their financial flexibility. Creditworthy hospitals also experience lower costs associated with their bond issues. I did a cursory study of the performance of A-rated and C-rated hospitals and noticed that the stronger organizations tend to consolidate markets by acquiring weaker competitors. Apparently, the latter can’t compete because they lack access to cost-effective capital. One author pointed out that winners in the competition for capital are hospitals and systems that can invest in their future. Capital-poor organizations are forced to sit on the sidelines, unable to expand or upgrade their facilities. (Coile 2002).

In the face of ongoing reform initiatives, the environment will only become more turbulent. Hospitals must adopt EMR or face reductions in their Medicare and Medicaid reimbursements. Rising bad debt and charity care are becoming contentious issues as several lawsuits filed by the IRS demonstrated. Commercial health insurance payments are in flux as more and more cost shifting related to consumer-directed health plans take root. A substantial number of hospitals with aging facilities are facing new financial and operational challenges. Tight labor markets continue to exert pressure on salaries and benefits. Regulatory compliance has multiplied and become more complicated. This has increased compliance costs. And competition continues to increase due to industry consolidation and the growing presence of physician-sponsored niche operations in the most profitable service areas. In the face of these sweeping challenges, my education will certainly prove useful!

Thank you again.

A BEST PRACTICE FOR BOSSES

One of the more difficult aspects of working for a boss is learning the boss’s communication and decision styles. Considering that the single most significant factor in determining your job satisfaction is your relationship with your boss, it pays to pay attention to that. In turn, when you’re the boss, you should communicate your personal style clearly.

(Dilbert's Pointy-haired Boss, inspired by my PM professor)

Here’s one technique I learned early in my project management “bossing” career from a mentor.

Create a list of guidelines for your team. Its purpose is to communicate the ground rules for interaction. This was one of my early lists.

1. I strongly believe in trust and dependability. If somebody says that they’ll do something, they should. If some unforeseen circumstance interferes, that person has the responsibility of notifying all that will be affected. If s/he wasn’t able to do that before the event, s/he must do it with an apology and explanation as soon as possible. And, may I add, to not do this repeatedly.
2. I will treat you professionally and I expect the same.
3. Refrain from accepting or committing to changes to the project unless you have that authority. All changes must go through the change control process. All requests, regardless of the medium it was sent in (e.g., email) must be transcribed to the official change request form.
4. Email headings. Maximize the use of the subject line. Identify the nature of the message according to its content. An email for action should be labeled ACTION. An FYI should be labeled FYI. Incidentally, I can’t think of any other type of email besides a Call for Action or an FYI. If I missed a category, please advise me.
5. Email headings again. Break the chain! At some point, it becomes silly to continue receiving and sending emails with the same heading over and over again. Here's what I mean: ACTION ----> re: ACTION ----> re: re: ACTION ----> re: re: re: ACTION ----> re: re: re: re: ACTION. Please break the chain!
   
6. Email length. Keep it to several paragraphs if possible. Longer content should be created as a separate document (e.g., Word or Excel) and attached to the email.
7. Email legalese. Our employer can legally monitor all email sent through its facilities. This includes your personal emails.
8. Email ccs and bccs. Refrain from carbon copying (that’s what “cc” stands for) and blind carbon copying (“bcc”) persons who do not need to know. CC-ing me to protect your rear may work but it may also lead me to form an incorrect impression about you.
9. Presentations. We’ve all heard of “death by PowerPoint.” If the expression is unfamiliar, please Google it. Learn how to make effective presentations.
10. Start and end meetings on time. Unless circumstances dictate otherwise, distribute the agenda at least 18 hours before the meeting.
11. It is sometimes easier to seek forgiveness than to ask permission. If you have to make a decision and, for whatever reason, you aren’t able to contact me or another manager, decide in the best interests of the company. You can do it.
12. I enjoy receiving most surprise presents from my family. I do not enjoy most surprises that come from stakeholders, customers, and fellow employees. Please advise me if you see something that should be brought to my attention.
13. Grammar and spelling. There are checkers in MS Word. Please use them. Typos and bad grammar annoy me especially if customers will read them.

PROJECT MANAGEMENT: A BEST PRACTICE FOR PREVENTING SCOPE CREEP

One of the most insidious things that will wreck havoc on your project is scope creep. The term refers to the addition of one addition after another to the original objective. The additions are usually done in a subtle manner and seem minor initially. Unchecked, you may find yourself with an objective that is more complicated, time-consuming, and expensive than the objective that was originally agreed upon.

Once a baseline has been created, there are only “preliminary” requirements and “baselined” requirements. Train your people to use these terms “preliminary” and “baselined” before the word “requirements.” Consistently using the adjectives will ingrain the fact that a baseline already exists and that any and I mean, any, other requirements are preliminary ones that are not part of the baseline. Consistently using these qualifiers reinforces the fact that all requirements are preliminary until they are included in the baseline.

One way that a customer or a stakeholder can try to introduce an addition is by insisting that his people meet directly with your people. He insists that he wants the information “raw.” He believes that if the information passes through the project management office (PMO), the information is filtered before it reaches him. As a Project Manager, you may have to permit his people meet your people directly as he requested. However, your permission should be given with the condition that your people are not authorized to accept or otherwise permit any changes to the original project objective. Any proposed additions must go through the PMO. Make sure that your people and theirs acknowledge and agree to that condition—in writing if you think that it’s necessary.

An effective way to create an environment that discourages scope creep is through the careful use of terminology. Here’s an example.

After the project’s scope has been agreed upon, the scope is captured in a baseline. This baseline is one of the most important documents in the project. Time and again, everyone from the project team to the stakeholders will return to the baseline. You might say that the project baseline is the reference standard of the entire project.

If you think about it, the baseline captures more than the project scope. It also incorporates the time and costs. The baseline typically takes the form of a tracking Gantt chart. A tracking Gantt shows the actual project’s progress beside the original forecast. The Gantt shows the project’s duration by task. The sum of task durations is the agreed-upon schedule (or time) of the project. The agreed-upon costs are visible behind the chart. The costs are shown by resources and the amount of resources used by individual tasks. These explain why the baseline is so important. It contains the triple constraints of scope, time, and costs.

The baselining, i.e., act of creating the baseline, is typically done at the end of the project planning phase. As the term suggests, the project has been planned and the stakeholders have signed off on the plans.

From that point, the Project Manager (PM) should clearly notify all stakeholders that from this point forward, the team will be strictly adhering to the change control process. The PM must emphasize the seriousness of the change control process. From this point forward, the PM must emphasize that the baselining process must be followed.

An addition, if it is accepted without going through a formal change control process, becomes a requirement. It becomes part of the scope. This is what scope creep is—the scope changes incrementally, i.e., it creeps.

Returning to that earlier example, the PM should instruct his team to never say or use the term “requirements” by itself. Again, never use the term “requirements” by itself with stakeholders and especially customer-stakeholders. Remind them that the scope and project requirements were already agreed upon and documented in the baseline.

Once a baseline has been created, there are only “preliminary” requirements and “baselined” requirements. Train your people to use these terms “preliminary” and “baselined” before the word “requirements.” Consistently using these adjectives will ingrain the fact that a baseline already exists and that any and I mean, any, other requirements are preliminary ones that are not part of the baseline. Consistently using these qualifiers reinforces the fact that all requirements are preliminary until they are included in the baseline.

Any change that pops up after the baseline is not included in the scope. It is referred to as a “preliminary requirement.” It stays preliminary until it goes through the change control process. If the change is accepted, then it turns into a “baselined” requirement.

I consider this to be a best practice for psychological reasons. Stakeholders, especially customers, tend not to take the original requirements of the planning seriously. Consequently, these stakeholders never treat the baseline with respect. Left unchecked, these stakeholders will continually submit new requirements and expect their acceptance without any consequences. That should not be the case. The baseline reflects everything that all stakeholders had agreed upon. Any changes have a “preliminary” nature until they are formally accepted.

It’s a subtle thing that works. Train your team to always make the distinction between preliminary and baselined requirements and the environment will change. Everyone will stay alert and know the difference between the original and the still-unaccepted requirements.

One of the most insidious things that will wreck havoc on your project is scope creep. The term refers to the addition of one addition after another to the original objective. The additions are usually done in a subtle manner and seem minor initially. Unchecked, you may find yourself with an objective that is more complicated, time-consuming, and expensive than the objective that was originally agreed upon.

Once a baseline has been created, there are only “preliminary” requirements and “baselined” requirements. Train your people to use these terms “preliminary” and “baselined” before the word “requirements.” Consistently using the adjectives will ingrain the fact that a baseline already exists and that any and I mean, any, other requirements are preliminary ones that are not part of the baseline. Consistently using these qualifiers reinforces the fact that all requirements are preliminary until they are included in the baseline.

One way that a customer or a stakeholder can try to introduce an addition is by insisting that his people meet directly with your people. He insists that he wants the information “raw.” He believes that if the information passes through the project management office (PMO), the information is filtered before it reaches him. As a Project Manager, you may have to permit his people meet your people directly as he requested. However, your permission should be given with the condition that your people are not authorized to accept or otherwise permit any changes to the original project objective. Any proposed additions must go through the PMO. Make sure that your people and theirs acknowledge and agree to that condition—in writing if you think that it’s necessary.

A practical way to create an environment that discourages scope creep is through the careful use of terminology. Here’s an example.

After the project’s scope has been agreed upon, the scope is captured in a baseline. This baseline is one of the most important documents in the project. Time and again, everyone from the project team to the stakeholders will return to the baseline. You might say that the project baseline is the reference standard of the entire project.

If you think about it, the baseline captures more than the project scope. It also incorporates the time and costs. The baseline typically takes the form of a tracking Gantt chart. A tracking Gantt shows the actual project’s progress beside the original forecast. The Gantt shows the project’s duration by task. The sum of task durations is the agreed-upon schedule (or time) of the project. The agreed-upon costs are visible behind the chart. The costs are shown by resources and the amount of resources used by individual tasks. These explain why the baseline is so important. It contains the triple constraints of scope, time, and costs.

The baselining, i.e., act of creating the baseline, is typically done at the end of the project planning phase. As the term suggests, the project has been planned and the stakeholders have signed off on the plans. From that point, the PM should clearly notify all stakeholders that from this point forward, the team will be strictly adhering to the change control process. The PM must emphasize the seriousness of the change control process.

The PM must clearly notify all stakeholders that, from this point forward, the team will be strictly adhering to the change control process. The PM must emphasize the seriousness of the change control process. From this point forward, the PM must emphasize that the baselining process must be followed.

An addition, if it is accepted without going through a formal change control process, becomes a requirement. It becomes part of the scope. This is what scope creep is—the scope changes incrementally, i.e., it creeps.

Returning to that earlier example, the PM should instruct his people to never say or use the term “requirements” by itself. Again, never use the term “requirements” by itself with stakeholders and especially customer-stakeholders. Remind them that the scope and project requirements were already agreed upon and documented in the baseline.

Once a baseline has been created, there are only “preliminary” requirements and “baselined” requirements. Train your people to use these terms “preliminary” and “baselined” before the word “requirements.” Consistently using the adjectives will ingrain the fact that a baseline already exists and that any and I mean, any, other requirements are preliminary ones that are not part of the baseline. Consistently using these qualifiers reinforces the fact that all requirements are preliminary until they are included in the baseline.

Any change that pops up after the baseline is not included in the scope. It is referred to as a “preliminary requirement.” It stays preliminary until it goes through the change control process. If the change is accepted, then it turns into a “baselined” requirement.

I consider this to be a best practice for psychological reasons.

Stakeholders, especially customers, have a tendency to not take the original requirements of the planning seriously. Consequently, these stakeholders never treat the baseline with respect. Left unchecked, stakeholders will continually submit new requirements and expect the acceptance of these additions without any consequences. That should not be the case. The baseline reflects everything that all stakeholders had agreed upon. Any changes have a “preliminary” nature until they are formally accepted. The distinction is subtle and should continually be pointed out. Train your team to always make the distinction between preliminary and baselined requirements and the project environment will change.

Through this practice, a PM will not be forced to implement the ban on unauthorized changes alone. Team members will stay alert and know the difference between the original and the still-unaccepted requirements. This involves them in the fight against scope creep. The team helps the PM with one of the most vexing problems that confront a PM during the execution phase of the project, namely, scope creep. Training your team in the manner described above turns the effort to control scope creep into a team effort.

PROJECT MANAGEMENT & ORGANIZATIONAL BEHAVIOR: THE RULES OF EFFECTIVE INFLUENCE

Influencing others goes a long way in becoming organizationally effective. And feeling better about your world and yourself.

Stephen Covey is my guru on this and all related subjects that pertain to effective people. Click here to read my blog entry about his highly acclaimed book, "The Seven Habits of Highly Effective People."

The power to influence others is important in any setting. Currently, more of my work is within the field of project management and I find that this subject has become more significant.

I’ve listed some practical guidelines below. None originated from me. Their “correctness” comes from their mention in other topics concerning human interactions.

1. In the short-term, you should build common interests through negotiation.

2. In the long-term, work on building trust, confidence, and respect for each other. If you have integrity and honesty, seek to demonstrate those qualities at every opportunity. If you don’t—well, you’re not my kind of a person.

3. Make hard decisions when necessary. However, be empathic with people who are adversely affected by those hard decisions. What’s empathy? To me, it’s being in the other person’s shoes and feeling what they feel and then returning to your own and communicating that you understand how they feel.

4. Avoid making enemies. An opponent is someone who disagrees with you and wants a situation to have a different outcome from yours. An enemy, on the other hand, is someone who has taken your disagreement to a more personal level and seeks to harm you. Discourage your opponents from becoming enemies by demonstrating genuine integrity and honesty. Do not be manipulative or double-cross them.

5. Be a worthwhile ally. This doesn’t mean that you have to offer your wholehearted and unreserved support for every action of your allies. Rather, it means that you should support people when they have worthwhile goals even if you do not directly benefit.

6. Do you know what a “fair-weather” sailor is? This is a sailor who sails only when the weather is safe and nice. Likewise, don’t be a fair-weather friend. Don’t demonstrate that you care about your allies only when the situation is safe. Demonstrate your support even if you expose yourself to political risk. In the long-term, you’ll earn not only their respect but the attention and respect of others.

7. Be generous with your favors. Do not dispense your favors conditionally. Do not dispense your favors on the condition that you expect an equal exchange or quid pro quo. Do favors when they are appropriate and within your power.

8. Ask for favors when you need help. Refrain from reminding those whom you seek help of any previous favors that you did for them. People of integrity will remember and act accordingly.

9. Keep your lines of communication open across barriers and, difficult as it may be, especially during times of conflict.

10. Make it clear by your actions and choices that you will do what’s right and beneficial to the organization.

11. Be aware that others do not necessarily follow the same code of principles that you do. Act with integrity but don’t be naïve to the reality of the behavior of others.

12. Do not win the battle and lose the war. There will be life after the most important project. Do not win at the cost of your principles. Take a long-term perspective. I know it's easier said than done. And even when I know, I still make some of these mistakes. That's what being human is, isn't it? We just have to try and keep on trying.

PROJECT MANAGEMENT: WHY "QUALITY" IS NOT THE THIRD CONSTRAINT.

From the beginning, project managers are taught about the triple constraints:
1. Time also known as Schedule
2. Cost also known as Budget
3. Scope also known as Performance

Time and cost are self-explanatory. When it comes to the third constraint, different terms are used: scope (the most common one), performance, and, sometimes, quality.

Scope is a description of the project’s objective in terms of the objective’s requirements. If the project’s objective is to create a water-powered car, then the scope includes everything necessary to develop that car. Developing a new engine that runs on water is part of the scope. So are the selection of the car’s body and the final assembly of the engine into the car body.

While the scope enumerates all of the objective’s requirements, it also requires the performance of these requirements. The project team must perform the development of a new engine. The project team must perform the selection of the car’s body. The project team must also perform the final assembly of the engine in the car body.

Would you agree, therefore, that the two, for all intent and purpose, are synonymous? In fact, it may be more accurate to refer to the third constraint as Performance. While scope enumerates the requirements, it is silent about the performance of these requirements. Performance, when identified as the third constraint automatically implies scope and, more importantly, the performance of those requirements.

Then there’s the third term that’s sometimes used to refer to the third constraint—quality. Quality is incorrect.

Neither Scope nor Performance is synonymous with Quality. Performance is what the project has to do. Quality is what the customer wants.

Every project’s goal is a satisfied customer, i.e., a customer that is satisfied because the project's objective was met. Does quality figure in the outcome? It sure does but the measure of quality depends upon circumstances.

Sure, we know that a best practice of project management when gathering the project's requirements is to ensure that fuzzy terms like "quality" are converted into measurable and objective metrics.

The following discussion does not contradict that. I am merely making the case that Quality is not the proper term to use as the third constraint.

PMBOK, itself, specifically identifies the triple constraints as scope, time, and cost (Section 1.3). Then it continues... "Project quality is affected by balancing these three factors. High quality projects deliver the required project, service or result within scope, on time, and within budget."

There is no ambiguity there. Quality is not one of the limiting three. Quality is a goal and not a constraint. Quality can be more closely related to the schedule or the budget, depending upon circumstances. Consider these two examples.

First: quality might be a function of time. Let’s say that you expect your wife to give birth within a two-week window from June 15 to June 30. You have to finish the baby room on or before June 14. You make it but the shelves haven’t been installed and the crib is only partially assembled. Wouldn’t achieving one hundred percent quality mean that shelves were installed and the crib was fully assembled? On the other hand, the project (of preparing the baby room) can be considered successful since it met the project’s objective satisfactorily.

Second: quality might be a function of the budget. Your project consists of replacing the worn kitchen countertops. Both of you decided to replace everything with granite countertops. Unfortunately, the week before your purchase date, the price of granite countertops doubled. That made it exceed your budget so you decided to settle on Corian—another material that cost as much as granite before its price doubled. Quality, in this case, is more closely related to cost. The kitchen countertop project was successful despite the fact that you had to settle for a less-expensive material.

Don't you think these makes sense? I welcome any comments.

Until then, I urge you to keep this in mind. The third constraint can accurately be identified as the Scope or Performance. But it should never be Quality.

To the left is a graphic that incorporates this fallacy. Out of professional courtesy I shall not disclose its source website.

PROJECT MANAGEMENT: HOW TO DEAL WITH VAGUE OBJECTIVES

It’s not unusual for an objective to be initially defined vaguely for any number of reasons. It may be a first-time objective. It may not have been thought through all the way and it’s your assignment to flesh the objective.

Do not make the mistake of accepting a project that has a vague objective(s)!

In fact, even if the objective seems straightforward, I think it’s a good idea to check it against your SMARTs. This familiar technique—you can google it easily—ensures that the objective is really clear. If it doesn’t pass your SMARTs, then you have to push back and insist on further clarification.

Remember, you have to clarify it before you accept it.

SMART is a mnemonic (ne-mo-nic) for the five standards that must be met by your project objective.

Specific + Measurable + Agreed-upon + Realistic + Time-bound


Here are the details.

Specific

An objective must have enough specific detail so you know what the final product or service is supposed to resemble.

Measurable

Quantify the objective and use an objective standard if possible and desirable. Reduce subjectivity since it leaves too many things open for conflict.

Agreed-upon

The standards of performance must be established before the project gets underway. This is especially important when there are numerous stakeholders.

Realistic

Negotiate. Exploit the flexibility of the triple constraints. Frequently, a project seems too difficult or impossible because of the project’s constraints. If the constraints are negotiable, risk is lessened and the likelihood of success improves.

Time-bound

A deadline motivates action. A lack of urgency tempts people to procrastinate. Always have a time constraint.

Additional Remarks:

The SMART process is iterative, i.e., it uses successive rounds to zero in on the most precise solution. Be forewarned that this is a time-consuming process. On the other hand, time-consuming as it is, you can be sure that it will save even more time by preventing (or at least minimizing) the chance that you will have to re-do the project.

Try to meet all stakeholders at each round of the process. Do this for everyone’s sake. Stakeholders who are neglected or even just feel left out frequently tend to put pressure elsewhere on your project. Invite them since you need to protect their self-esteem and sense of participation.

Summarize and paraphrase each stakeholder’s input until the stakeholder agrees that you, the PM, understands.

At the end of each round, prepare a draft statement of the negotiated objectives and circulate it. Invite feedback and discussion.

You’ll know that the objective is clear when it passes the SMART test and is accepted by all stakeholders. Ideally, this group should include even those stakeholders whose objectives were eliminated. This group may not like the final decision but the important thing is their acknowledgment of the fact that their objectives will not be in the final project. Remember: the objective has to pass the SMART test and is accepted by all stakeholders.

CONSTRUCTIVE CRITICISM

Constructive criticism is an oxymoron.

People judge others by their behavior, but themselves by their intentions.

Again: People judge others by their behavior, but themselves by their intentions.

Most people's intentions are positive. However, even the best-intentioned action can produce a negative outcome. Instead of judging someone’s motives based on your perception, try to identify that person's intention first. If you can understand that it was positive, you'll be less critical. In any group environment, others will respond better and think of you better if you are less critical.

What's the key? Match a person's intentions with their behavior.

I'm currently pursuing a Master's degree in Project Management. I picked this useful tidbit about human behavior from one of the courses. I've generalized the principle here.

PROJECT MANAGEMENT: HOW TO HANDLE A PROJECT WITH TOO MANY OBJECTIVES

Project objectives are usually negotiable. It’s not always a situation where, as the saying goes, “it’s not for me to reason why but to do and die.”

Most conflicts about objectives occur because of multiple stakeholders. Each stakeholder wants his/her objectives included in the project. If you know it’s not possible, say so! If you don’t, you’ll suffer a thousand deaths.

I know because that’s what happened to me the first time. Fortunately for me, the second time this situation confronted me, a more experienced PM (Project Manager) came to my rescue and taught me the following techniques.

Begin by identifying the disparate objectives. Categorize them by type, purpose, stakeholder, and any other salient attributes, e.g., duration, cost. Most of all assess each objective’s feasibility according to your project constraints. For each project objective, distinguish between what’s being asked as opposed to what’s feasible.

You may find that it’s actually possible to accomplish all the objectives but not within the original constraints. This gives you a good reason to approach your project sponsor or customer, explain the additional objectives and how achieving them will add value. Then ask for their decision. If they want to proceed with all those objectives, request for the additional resources. Either way they know the situation and must live with the consequences of their decision.

If you don’t receive the additional resources and they still insist on all the objectives, you have to let them negotiate with each other. Explain very clearly that you can’t do everything that everybody wants given the constraints you have. Explain, therefore, that some stakeholders will not see their objectives included in the project.

For specifics, try taking these steps:

1. Convene the stakeholders who are most likely to be affected. Let them negotiate with each other. Request them to tell you their decision. If they won’t or can’t, then…

2. Rank the conflicting objectives according to the value that will accrue to the customer or your organization. Select the highest value objectives. If the highest value objective isn’t clear, then…

3. Bring your project sponsor into the situation and request him/her to help the stakeholders resolve their conflict. If that doesn’t work, then…

4. Select the objectives that will satisfy the greatest number of stakeholders. If that doesn’t work, then …

5. Escalate it to your sponsor or superior and request them to make the decision. If that doesn’t work, then…

6. Select the objectives according to their duration (faster wins over slower), difficulty (easier over harder) and simplicity (simple over complex).


Credit for helping me develop some ideas go to Mike D.

PROJECT MANAGEMENT: REALISTICALLY CONSIDER THE BUDGET

Realistically consider the budget!

A project has five major elements:

1. The budget
2. The schedule
3. The people
4. The resources
5. The rules

Project management has many aspects but all of them fit under these categories.

Why is budget listed first?

Well, isn’t cost usually the first thing the project sponsor brings up?

In fact, isn’t cost frequently brought up in the same conversation that sparked the project idea?

Doesn't it make sense therefore to immediately consider it?

If the sponsor wants to build a new $1 million data center and is suggesting that it can be done for $600,000, then maybe the project idea should be squelched right there and then.

Let's say that you were able to persuade the sponsor to increase the budget to $1 million. Is everything fine? No. It's easy to overlook a related aspect, namely, the scope. Specifically, you want to ensure that the budget is appropriate for the scope of the project. It is time, therefore, to define the scope.

Doesn't this approach run counter to the "normal" process of defining the scope before estimating the budget? On the other hand, doesn't the example given happen more frequently in real life? Reality often does not follow the textbook model. In this case, it certainly doesn't. The budget often precedes the scope although conventional project management thinking says that it should be the other way around.

Let's say that for any number of reasons, many of which were beyond your control, the new data center was finally finished at a total cost of $1.2 million. Now the question is whether you think the sponsor will consider the project successful?

What do you think?

The sponsor will probably not consider it a successful outcome unless they were forced to approve every change and/or activity that increased the total bill by another $200,000. An over-budget situation can be avoided by two things: first, ensure that the budget is appropriate for the project scope, and second, implement a strong change control process over the project cycle.

Where does the project scope fit in? As its own entity, it doesn’t. However, the components that comprise the project scope do. These components are the budget, the schedule, and the resources (including the people). As you can see, the project scope will fit once it is decomposed into its four elements.

It’s human nature to try to get more for you money. It’s suicide to accept a project that has an unrealistically low budget relative to its goal. Let’s keep that in mind.