Constraints Drive Innovation

Amazon founder, Jeff Bezos, gives his take of business innovation, which he believes it driven by constraints that forces us to create new ways to approach the situation. ...

... "I think frugality drives innovation, just like other constraints do. One of the only ways to get out of a tight box is to invent your way out. " ...

Via Business Week: Jeff Bezos

Project Risks; Let's Talk About the Weather

When doing risk planning for your project, don't forget about seemingly off-topic risks, such as the weather, or the season of the year. It's an obvious concern if you're in the construction or farming industry, but in many other organizations, timing your project rollout to avoid quarterly closes, the company's peak season, or any other major seasonal events, can make or break your project.

I've heard of one popular confection organization that couldn't ship candy during Halloween because of a problem with their new SAP implementation. Bad timing. Another company that dealt with agriculture had to have a project completed before the summer growing season. They were smart enough to list that as a constraint.

The seasonal elements didn't just affect Napoleon in his failed Russian campaign (and many before and after him). It can affect those of us in business as well.

Microsoft Vista Project Management: Scope or Schedule Management ...

Microsoft struggles with Vista project management. Working the triple constraint, Microsoft adjusts scope and schedule - and, likely, costs are increasing as well. Article explores options for improvement, including ruthless schedule management, better requirements management, etc. ...

... "With Vista, Microsoft originally hoped to make major changes to the underlying code, adding in a new file storage mechanism called WinFS, along with all-new graphics and communications methods. It eventually had to pull out WinFS entirely and scale back several other architectural changes in order to make the project more manageable. " ...

Microsoft Vista Project Management: Scope or Schedule Management : Clouds over Redmond: Via ZDNet Australia ...

Project Management Useful Analogies (or Jokes)?

Some of these you may have heard, some perhaps are new. Sometimes helping people to understand requires an analogy or "funny" anecdote. Let us know if any of these work for you! My comments are embedded here for you also in brackets [].

1. It takes one woman nine months to have a baby. It cannot be done in one month by impregnating nine women. [my favorite - throwing bodies at the problem is usually not the right answer]

2. Nothing is impossible for the person who doesn't have to do it.
[watch it when someone says that someone "JUST" has to do X]

3. You can con a sucker into committing to an impossible deadline, but you cannot con him/her into meeting it.
[when they squirm about a date, figure out how to help them and note the risk]

4. At the heart of every large project is a small project trying to get out.
[break the work into "bite-sized chunks"]

5. A user will tell you anything you ask, but nothing more.
[requirements gathering - yeah, good luck with that. better to observe them in action, and show them prototypes and let them react.]

6. Of several possible interpretations of a communication, the least convenient is the correct one.
[true!]

7. What you don't know hurts you
[also known as "the devil is in the details"]

8. The bitterness of poor quality lasts long after the sweetness of making a date is forgotten.
[read that one again]

9. Everyone asks for a strong project manger - when they get one, they don't want one.
[amen!]

10. Fast - cheap - good - you can have any two.
[see other posts on the triple constraint]

Thanks to www.funny-haha.co.uk for these! See that site for many more!

Project Estimating; Triple Constraint Must Stay Firm

Here's a great article from TechRepublic about project estimating and forecasting. It cautions that one of the worst things to do is to try to force a project to fit within an arbitrary management deadline. That means project managers must defend the right plan or suffer with poor results.

A properly estimated project must be based on planning, and be managed to the triple constraint of scope, time and cost (and of course, at PMThink we've discussed other potential variables, such as quality, risk, customer satisfaction, and more).

Here's TechRepublic's advice to CIO's:

Project managers talk about a project’s “triple constraints” of scope (work), time (schedule), and cost (budget)... For the team to make decisions that are closely aligned to the way you would like them to be made, you must clearly state the project priorities. There’s no such thing as “all three variables are equally important.”

Read on for more details or proper estimating and forecasting...

How to accurately estimate and forecast in project management

Extreme Project Management (XPM): When Under the Gun, It's the Only Way

I must confess I'm a big fan of Extreme Project Management, otherwise known as XPM or Agile Project Management, in the right circumstances.

This is not the antithesis to traditional PMI processes; it merely takes a more realistic approach to project situations where there is great uncertainty (like many IT projects) or a severe time constraint (like many IT projects).

The key to making it work is a heavy focus on stakeholders and constant communication. It is anything but a "wing it" approach, as I've written about on PMThink several times. As opposed to "mechanistic" processes, which is the focus of typical Business Process Modeling (BPM), it relies on human interaction management, which addresses "human-driven" processes.

Here's the Wikipedia entry on Extreme Project Management, for more info. Also, be sure to check out the link to Human Interaction Management for examples of human-driven processes.

Extreme project management - Wikipedia, the free encyclopedia

Evaluating Project Tradeoffs: Some Guidelines for Success

Anyone familiar with PMI principles knows the triple contraint of time, cost, and scope, and the fact that it can be used when negotiating tradeoffs. You're probably also familiar with additional tradeoffs, such as quality/grade, risk, customer satisfaction (if that's even a variable), etc.

When negotiations come to a grinding halt, we also have some other proven tools to keep in our back pocket, including:

• Fast Tracking (doing some tasks in parallel that would usually be done sequentially, which of course should be used carefully since it can add risk)
• Crashing (loosely defined as analyzing alternatives to compress the duration for the least amount of additional cost, but typically interpreted as adding resources or forcing overtime, which carries risk and adds more cost than people realize)
• Time-boxing (reducing functionality for the first release and moving it to a future release)
• Problem solving (i.e. considering other approaches to solve the root problem)

In my experience, the two methods that work best by far are time-boxing and problem solving, usually in that order, and often in combination. I also find that time tends to be the most frequently stated hard constraint, with scope and even cost somewhat more flexible (although the requester rarely admits that).

Usually, scope is the most flexible (some argue over semantics of scope vs. features/functions, vs. deliverables vs. sphere of implementation, but I tend to lump it all under "scope").

And of course, when it comes to overarching priorities, I always fall back to my own tried and true "two-sentence principle", which I stated a few weeks ago:

Speed is more important than cost. And success (in whatever form that takes) is more important than speed.

In countless IT projects, these guidelines have served me well. I'd be curious about others experiences when making tradeoffs, especially in other industries.

More Project Management Equations; The Triple Constraint Override

With nearly 30 years in IT, I've come across pretty much every situation, whether it was managing commercial software product development, acquisitions and divestitures, systems conversions, you name it. And over that time, certain things jump out as tried-and-true principles.

One of them I call the triple constraint override. That is, irregardless of the usual triple constraint of time, cost, and scope (I won't get into the other four possible constraints), I have my own principle that overrides all that.

It involves two simple equations:

Speed is more important than cost.
Success is more important than speed.

In other words, if we act fast, cost will usually follow naturally. Delays can increase cost exponentially, whether it's the cost of lost opportunity, the cost of reduced momentum, or any other number of costs associated with the risks of delay. Sometimes, it might appear that we're spending more money by rushing (such as paying a little more for a service rather than waiting to get the best deal), but in the end, what is really saved by waiting? I argue that there are hidden costs in waiting that can negate any gains.

But even speed must take a back seat to success. Notice I didn't say quality. That's because it's not about perfection. It's about the success of the project, whatever you take that to mean. If speeding things up risks the success of the project to the point where there's a 50% chance or less of success, then the speed has turned into haste and it's a sign to slow down and develop a more realistic plan.

Like any rule or principle, there are exceptions, especially during some negotiation situations. but we must consciously make that decision after weighing the situation against the two simple equations I've mentioned.

Just something I thought I'd pass along.

Project Success Equation; The REAL Triple Constraint

We've all heard the issues over the triple constraint, and whether it should include scope, time, and cost, or other factors as well. But the "real" triple constraint often goes unnoticed. And that is the old trio of "people, processes, and technology".

We need to invest in all three in order to have project success. By "people," I'm not only referring to investing in leadership training for project managers, but also to having an organizational structure that's aligned and not set up for conflict.

And, while processes are critical, some things cannot be "processized," such as leadership and stakeholder management. And processes alone, without the technology to make it efficient, can also be a burden.

So next time you're analyzing the success or failure of your project, consider the impact that people, processes, and technology had on that result. There may be some eye-openers.

Project Management: Time-Based Performance Criteria

Timing constraint set in large state-wide wireless network project. Ethan Butterfield reports on the challenging project performance criteria being used on NY network project. Contractor will be only be paid upon delivering each phase. ...

Project Management: Time-Based Performance Criteria: Via Washington Technology: New York dares to dream

... "It is crucial that the project management team make certain the timing of these deliverables don't slip, either because of vendor action or inaction by the state, Kost said. Time is money to all parties, and state decision-makers must bring the same sense of urgency to decision-making that the vendor will bring. " ...

Leadership Constraint: Time Management

Leadership Constraint: Time Management: Via SiliconIndia: Mark Of A Leader ...

Project managers need to manage their own, their team's, and their sponsors (leadership) time well. This article explores the challenges and qualities of leadership. Project managers that exercise these competencies prepare themselves for their opportunity in executive leadership positions ...

... "Time Management. Everybody wants a leader's time, just the thing that he or she does not have a lot of. In a sense, the only gift that anybody can give a leader is time, and the only way to do that is by not taking up her time. Messages or ideas should be conveyed in as little time and as efficiently as possible. " ...

How many elements are there in the triple constraint?

In addition to the normal triple constraint elements:
1) Time (or schedule)
2) Resources (effort and/or budget)
3) Scope
discussed in this article, there are two other important elements to every project:
4) Quality
5) Customer Satisfaction

What if you delivered the scope on time and on budget but it wasn't up to the quality standards of your customer (or user of the product or service)? Would your project be a success. I think not! And what if you delivered the full-scope, it met the customer's quality expectations, was delivered on time, on budget, but you and your team were extremely difficult to work with? Would the project be a resounding success in your customer's eyes? Would they want to work with you again? Most likely not.

The article is dead on, though, in suggesting that the PM should be sure to ask the sponsor(s) to prioritize the "triple" constraint at the beginning of each project. Just remember that there are 5 elements and they are all important!

Triple Constraint--Friend or Foe?

Project Estimating; Major Causes of Underestimating

Another gem from Conrad Weisert of Information Disciplines. An oldie but goodie (the article, not Mr. Weisert).

This article is a call to project managers to stand up for realistic estimates. Of course, there are always those times when a project must come in on a certain date or else the project just isn't worth doing or won't have the impact it needs.

But even then, you need to ask yourself how risky it is trying to meet that date, and what are the consequences if you do not succeed. If both the impact and probability of failure are high, then it's imperitive to ground the estimate in reality.

Sometimes additional resources can help. Sometimes it adds more risk. It all depends on the situation. In the end, the triple constraint still holds true. The scope, time, and cost must balance.

Read on for more info...

Burden of Proof in Project Estimating

Managing Projects with Unrealistic Deadlines

One of the most frustrating challenges for project managers is attempting to manage a project with an unrealistic deadline, especially if the date seems arbitrary. This excellent and insightful article from TenStep, Inc. (note the link to view the PDF version) explores several approaches one can take to deal with this common problem, including:

• Using the triple constraint of time, scope, and cost to make the case for adding time, reducing scope, or adding resources/cost if appropriate
• Pointing out the risks early and managing risks tightly
• Considering reducing the scope
• Aggressively monitoring the schedule and raising issues immediately
• Involving the sponsor in offering ideas for meeting the date
• Exploring other project approaches or methods that may shorten the time
  
  Read the article below for more details.
  
  Managing Projects with Unrealistic Deadlines