Lean Partner Teams

The integration of enterprises through global sourcing strategies is a common occurrence today. As part of its sustainability strategy, Nike works with its partners in the value chain to drive principles to the team level and develop an empowered extended workforce. ...

... "Lean principles put the decision making closer to the worker through skill building, teamwork and understanding quality over quantity. HRM builds the factory’s managerial capacity and helps them value an empowered workforce. " ...

Via Nike: Sustainability Strategy

Insights into Agile Software Release Management at Salesforce

Insights into the monthly software development rhythm at Salesforce.com which drives their three releases per year ...

Embrace Toyota Kaizen

Here's a set of leadership principles that contribute to the success of the Toyota production system. These can translate well into the field of project management. ...

... "Advancing your team member's careers by walking along side them on their learning journey, mentoring them and keeping them from wavering on the path of the creative thinking process is also a leadership habit kaizen develops. " ...

Via Manufacturer.com: Kaizen Leadership Development

Principles and Symbolism Compromised

Are principles compromised when reward, risk, and investment are out of balance? ...

... "There is no sense of shared enterprise at most firms, and no belief among the rank and file that they should have to pay a price if the firm is drowning in losses and needs government support. " ...

Via New York Times: It’s the Principle

The Project Design Task

Most of our projects have some type of design task in them. But what is an exceptional design? Here are some principles to anchor your thoughts. Think - usable, resilient, conscientious (or sustainable). Read on. ...

... "The best designs influence and enhance many aspects of our lives through interaction with those products/services - from our buying experience, to the delivery and packaging, to installation and use, to other products/services that complement it, to customer support and maintenance, all the way through end-of-life and disposal. " ...

Via KiteTail: Principles of Good Design

Project Lessons from a Disney Vacation

I recently returned from a vacation to Disney World with the family. I hadn't been there since 1984. Still beautiful. Still a shining example of unparalleled customer service and impeccable presentation.

A few thoughts came to mind while I was there.

1) Words matter. They refer to their employees as "cast members" and their customers as "guests." These are far more than words. They create a mindset that encourages everyone to live the Disney principles. What words can we use that will change the mindset of our people?

2) When it comes to managing projects, Disney has their act together, as evident by the sheer magnitude of their accomplishments and their feats of logistics and technology. I'm now reading The Disney Way, by Bill Capodagli and Lynn Jackson, as well as Inside the Magic Kingdom by Thomas Connellan to find out a bit more (both are excellent books). Right off the bat, I'm seeing that prioritized core values combined with common sense, appropriate risk-taking, extensive training, and long-term thinking permeate everything they do.

The core values are especially critical, and are what has helped Disney begin its return to form, after a slight detour during an internal civil war (read Disney War, by James B. Stewart).

More to come.

3) Even our own vacation experience brought an interesting lesson. When preparing for a vacation, I typically do extensive research, exhaustively reading every book on the destination (not unlike Napoleon preparing for a battle). But once I'm there, I'm not so hung up on sticking to a rigid schedule. I like to allow for random discoveries (also not unlike Napoleon).

In this case, we had to reserve the dinners months in advance, so we planned a loose agenda around that (by loose, I mean we planned which parks we wanted to visit each day, along with attractions we didn't want to miss, but we kept things open otherwise). On day 4, we intended to go to Disney's Hollywood Studios, and day 5 our plan was to visit the Animal Kingdom.

The days were mostly 80 degrees and sunny. But lo and behold, on day 4, it was cool and slightly drizzly in the morning. As we waited for the shuttle bus to take us to Disney's Hollywood Studios, I noticed another bus came first---the bus to Animal Kingdom. I made a quick decision, suggesting we hop on the Animal Kingdom bus instead. Of course, my wife looked at me like I had two heads ("What, you're going against the plan???") and my daughter just followed along (she's 6).

Here was my rationale. Having done the research, the Animal Kingdom has no shade and can be exhausting on hot days. By siezing the moment, we could use the cool, overcast day to our advantage at Animal Kingdom, and visit the Hollywood studio the next day.

We hopped on the Animal Kingdom bus, and, luckily, it worked out perfectly. It also served as a reminder that, despite whatever plan may be in place, it pays to be flexible and seize an opportunity, even if it means altering the plan.

Project management is not about blindly following a rigid plan, ignoring the variations that reality brings. It's about doing the up front research, planning, and then adjusting to the current situation and latest information. That's quite a bit different than "winging it."

End of sermon.

When Rules Attack: The Death of Common Sense

Most Americans, and I'm sure those in other countries as well, have seen their share of unnecessary bureaucracy. This not only permeates our government, but our organizations as well.

How many organizations add rule after rule in order to combat uncertainty, without realizing that they're also digging their feet so deep in the mud that they cannot walk?

I've long contended that principles work better than rules, with very few exceptions. A book I'm reading, The Death of Common Sense, by Philip K. Howard, makes this case quite effectively.

The back cover of the book states:

- Why did the New York City Building Code crush Mother Teresa's plans to build a shelter for the homeless?

- Why do your tax dollars pay for policing elementary school art displays?

- How did a handicap-access law deny public bathrooms for thousands of able-bodied people?

How much collateral damage has been caused in your organization as a result of overzealous compliance departments or rulemakers?

A paragraph in the book puts it quite nicely:

Principles are like trees in open fields. We can know where we are and where to go. But the path we take is our own. What good is law today? We fight off rules like branches hitting us in the face, losing any sense of where we are supposed to be going and bleeding from illogical dictates that serve no one's purpose... The sunlight of common sense shines high above us whenever principles control: What is right and reasonable, not the parsing of legal language, dominates this discussion.

"Discussion" is the operative word. If we used common sense, and engaged in meaningful discussion---looking at things on a case-by-case basis---we could do away with much bureaucracy and reduce "one size fits all" thinking.

Certainly, there are times when rules or standards are needed. These boundaries should be defined and agreed-upon. But for every rule, we should be asking: Is there a guideline or principle that would work better, and enable people to use common sense?

Food for thought.

What is a Project? Think Again!

Max Wideman’s very impressive Comparative Glossary of PM Terms contains 23 different definitions of the word project – all written by very knowledgeable people. Creating a sticky definition of the word “project” (a sticky definition is one that can be easily memorized by a general audience) requires battling the Curse of Knowledge. The Curse of Knowledge is the result of forgetting what it’s like NOT to know what you know. The more you know, the stronger the curse. That’s why truly sticky ideas often come from unexpected sources, and different fields. (Unexpected is one of the Made to Stick principles.) In my opinion, the very best definition of the word project comes from personal productivity guru David Allen, in his brilliant book Getting Things Done. Here it is...

• A project is any outcome you’re committed to achieving that will take more than one action step to complete.

Why is this a great definition?

(1) This definition is water tight. Unlike the other 23 definitions, I can’t think of a single exception to this definition. (If you can, please post a comment.)

(2) The word outcome covers a lot of PM territory. The word outcome includes the concepts of “deliverables” and “creating unique products, services or results.” It applies to your garage project and it applies to “landing a man on the moon and returning him safely to earth.”

(3) The word action captures an essential element of every project – making progress one discrete step at a time.

(4) The word committed filters out activities that are not projects.

(5) The three key words outcome, action, and committed are simple and concrete (two more Made to Stick principles).

Most of the definitions in Widemans’s glossary define projects as the way very knowledgeable people LIKE TO MANAGE projects, especially large ones. Knowledgeable project managers like clear specifications (or user stories), they like budgets and change control, they like project-friendly cost accounting, they adore network schedules (or iterations), they like to manage risk, they manage resources, they create return on investment in their project portfolio, etc. There's nothing incorrect about any of these ideas, but these XL clothes don’t fit very well on small projects. After all, small projects are projects too, and there are far more small projects than there are large ones!

Example: If we are visiting a science museum (just a casual visit) it is certainly not a project. However, if we are committed to organizing a safe, enjoyable learning experience at the science museum for a large group of Third Graders, our project is the set of actions that we take to achieve this intended outcome. It isn't about abstractions like temporariness and uniqueness. This project does not have a budget, it doesn’t have a logic-driven schedule network, there’s no accounting system, there are no deliverables, we might repeat the adventure every school year, and it isn’t formally risk-managed or resource-managed. But anybody that has organized a major field trip for a large group of kids knows that it is indeed a project! Why? Because it has an intended outcome, it has action steps, and it requires commitment.

David Allen's definition deserves to be in the Hall of Fame of Sticky Ideas.

P.s., Thanks for reader Kurt U. for prompting this post.

Periodically Recenter on Your Principles

Take a break. Reconnect with your principles. ...

... "Am I doing everything possible in my current project to hold to the principles that got me into all this? " ...

Via tompeters!: Succeed

The Enemy of Simplicity: The Thud Factor

We've all heard about the benefits of simplicity, whether in our processes, our communication, or in our objectives. In all its forms, simplicity is a way to reduce confusion, boost morale, and encourage speed and flexibility. In fact, simplicity, speed, and flexibility are three of the "Six Winning Principles" I wrote about in Napoleon on Project Management (the other three being exactitude, character, and moral force).

But there's a lurking enemy of simplicity, and it often goes unnoticed. It can be found in the motives of individuals creating the processes, communications, or objectives. I'm talking about job protection. I don't mean the blatant kind that results from grandiose thinking, egotism or turf wars. It's much more subtle than that.

It can happen if an individual or department is placed in charge of creating a process or devising a plan. Or it can happen if a consulting company is brought in to do a study or offer advice. Common sense says that these people, while not necessarily devious, will hesitate to come up with anything too simple, lest they feel they're not doing their job. The result is often something that is way more detailed, complex, and expensive than it needs to be.

What can we do about it? We need to be very aware of motives and rewards, and make sure we don't consiously or unconciously reward people for complexity. We need to send a message that the shortest, simplest way to meet the goal wins (even offering incentives if possible). This can avoid what many consultants jokingly refer to as "the thud factor"----the customer's perception of the value of the service as judged by how much of a noise the report makes when it's dropped on their desk.

Whether it's a consulting company, a PMO, an internal process center, or a project team, we need to find a way to head off the thud factor and insure simplicity. We can do this by understanding motives; sending the right message; insisting on brief, simple reports; and creating the right reward system.

ITIL Accelerator Tool

Tool accelerates ITIL implementation through reusable business process models. ...

... "ITIL, published by the British Office of Government Commerce, is grounded on fundamental principles such as client orientation, service level agreement, and quality management. The MEGA ITSM Accelerator is a graphical, ready-to-use repository of ITIL best practices. It enables IT managers to deploy these best practices in a consistent framework, thus reducing project risks and implementation costs. " ...

Via MEGA International: MEGA International Releases Advanced MEGA ITSM Accelerator

Executive Support

Continuing the series of posts on Critical Success Factors, we get to Executive Support. This topic is easy to understand. It's also easy for people charged with establishing a PMO to blame lack of executive support for problems they encounter. The fact is that the kind of executive you would want as a sponsor is high enough in the organisation that they will be too busy to give detailed support. So it is essential to have a common description of the relative roles of the change management team and the executive sponsor.

Some commonly quoted expectations for executive support are:
- Visible enthusiasm within the organisation for Project Management philosophy
- Advocacy between organisational groups
- Creation of, or active support for, a vision for the organisation with engrained project management processes
- Removal of barriers to change
- Assurance of funding for the implementation and continued operation of the PMO
- Enthusiasm for the use of project management information and involvement in the processes

It's important that the support should be actionable at a working level. For instance, providing some high level design principles but not insisting on detailed design approval. Or, issuing a public announcement which would then be followed up by detailed posts about specific topics from the team.

This paper describes a sponsor's role in developing project management maturity.
The Executive Sponsor - the Hinge upon which Organisational Project Management Maturity Turns?

Is Project Management Relevant?

Over the years, I've had discussions with software developers who question the need for project management. I've heard everything from "The developers are the only ones who really know what's needed anyway!" to "All the project managers do is slow things down and add unnecessary bureaucracy!" to "Why can't the the developers just work with the customer to give them what they need and avoid the middleman?"

The fact is, given the right developer and a fairly isolated project, all of these are valid statements. But many projects are much more complex than that. They involve multiple stakeholders with conflicting needs, offshore resources, multiple vendors, complex interrelationships with other activities and departments, and more. They frequently involve managing all of this against budget and schedule constraints.

Leading, facilitating, and managing all of these elements is where a good project manager can help. An effective project manager removes barriers for a team rather than adding barriers. Any activities that may appear like "nuisance work" to technicians, such as reporting time or percent complete against milestones, are often necessary to meet the project's schedule or budget constraints.

A good project manager will work with developers to determine the appropriate project approach, depending on the constraints and the level of uncertainty involved. Perhaps an agile approach is warranted, with learnings applied incrementally. Perhaps piecemeal deliverables can be achieved for quick wins and earlier value. A good project manager will also prepare management reports, conduct presentations, and deal with vendor issues.

Most of all, a good project manager will communicate to all parties throughout the project. Although some developers do indeed have the expertise to do all this, it distracts from the work they need to do.

This is not just a nuance of the software industry. The same holds true in any industry where technical or subject matter experts question the need for project management. Project management is a completely different skill set, necessarily so. It's geared toward leading people to achieve objectives. An organization can of course put the project manager in a better position to be successful by providing adequate tools, general principles, and minimal bureaucracy.

The article below offers clear and simple evidence of the importance of project management. It begins with the results of a 1999 study that showed that the number one reason companies stopped working with Internet design firms was not about their lack of creativity or high costs---it was about their inability to effectively manage a project.

Here's the article...

MB Journal Article Archives

Project Management Imperatives: Ten Keys to Success

Someone recently asked me what I felt the critical success factors were for any project (i.e. what were the top "must do's"). Although I can think of many more, here were what I felt were the top ten:

1) Get the roles right. (Insure accountability; use a RACI chart or Responsibility Matrix so roles are clearly defined. Insuring people understand their commitments up front will avoid problems later.)

2) Get the goals right. (Make sure all the key stakeholders agree on the goals. I've seen more projects go wrong for this reason than any other. Time spent here will pay dividends later.)

3) Get the current scope right. (I say "current scope," because change should be expected. Projects by default contain change because they are unique in nature. It's not whether you'll experience change, it's how you analyze the potential impacts and manage the approval of the change that counts. Agreed-upon and approved scope changes are perfectly acceptable, with one caveat: It's often wise to set a limit to the number of times scope can be changed for the current product release, and defer some changes to a subsequent release, else value gets delayed.).

4) Obtain commitment from the business, customers, and other stakeholders as to their part in the success of the project. (Many projects derail because the customer doesn't live up to their side of the bargain, doesn't understand their side of the bargain, or some other necessary constituent isn't cooperating for various reasons. Obtain the right commitment up front, starting with senior management.)

5) Determine the critical success factors and risks. (Critical success factors and risks go hand in hand. Many people ignore this or sweep it under the rug, and accept any related risks as a given. The critical success factors will identify related risks and help set expectations).

6) Set expectations. (This is frequently overlooked and is a key cause of failure. The sponsor, customers, and anyone impacted by the project must be given realistic expectations for what is needed from them, how long the project will take, how much it will cost, what the uncertainty factor is, what the available resources are, and anything else necessary to avoid surprises and/or an under-equipped effort.)

7) Beware of conflicting directives. (I call this the "Robocop Syndrome." In the film, Robocop, the titular robotic policeman goes on full tilt when he encounters directives that conflict with his primary directive. I see this happen often in organizations where a project sponsor demands something that is in conflict with other key stakeholders' wishes and/or top organizational directives. This could be covered under "goals" or "expectations," but it's so important that it warrants its own point. The project manager must head this off at the pass before the project goes down a rat hole it won't recover from.)

8) Plan Collaboratively. (The act of planning is not an isolated exercise. It's a collaborative exercise and should be done with the project core team and subject matter experts via some sort of facilitated brainstorming session---possibly with sticky labels on a wall.)

9) Beware of unilateral and granular "one-size-fits-all" solutions. (This is often ineffective, both as a project management methodology and a process implementation policy. Look at the big picture, and the potential variations. Keeping a framework high-level can allow for greatest flexibility and adaptability. Aim for principles over rules wherever possible. Use rules when safety is involved, regulatory requirements exist, or exact accuracy is needed---per Marcus Buckingham's guidelines from "First Break All the Rules.")

10) Don't let rank set you off course. (Often, a senior manager pulls rank and makes requests that are either detrimental, unwise, or in direct conflict with organizational goals. When this happens, see rules 6 and 7. It is the project manager's responsibility to set the right expectations, warn of potential risks, and head off potential conflicting directives at the pass.)

There it is. My list of "must do's." Project management isn't rocket science. In fact it's not a science at all. It's more of an art. Hopefully, the guidelines above can serve as a useful palette.

Project Proposal: Pitch the Business Case

Guy's partner, Bill Reichert, offers sage advice on pitching business plans to venture capitalists, investors. These same principles apply to project proposals for your investment portfolio. A concise, yet informative, pitch makes a governance session efficient and effective. ...

... "Pitching is about understanding what your customer (the investor) is most interested in, and developing a dialog that enables you to connect with the head, the heart, and the gut of the investor. " ...

Via Guy Kawasaki's How to Change the World: The Entrepreneur's New Year's Resolution: I Will Fix My Pitch

Control vs. Accountability: Are We Our Own Worst Enemy?

In our never-ending struggle to gain more control over the chaos in our organizations, and with more and more focus on change management, who would think of going in the opposite direction and allowing more freedom?

Let's take a look at a story with some surprising results (sent courtesy of my old friend, Larry Beane).

Thanks to a project initiated by the European Union, seven sities and regions in Europe have completely done away with traffic signs. The originators of this idea must have been on to something. Contrary to the normal expectation that this would result in pandemonium, the accident rate went down!

Now arguably, this may or may not work in a congested city, but it got me thinking about the need for accountability. Perhaps the more rules we inflict, what we're really doing is relieving people of accountability---the paradox being that we need to give people freedom to make them fully accountable. Otherwise, we claim ownership of the problem instead of delegating it.

This is not unlike Toyota's policy of trusting their work teams to solve problems independently, and trusting that if their solutions are wrong, they'll work to correct it and learn from the experience. This is what a learning organization is all about.

This isn't to say we should just abandon all change management processes. On the contrary, providing people with effective processes can lead to successful outcomes. But for each rule we devise, we should consider an alternate approach of holding people accountable for outcomes, and insuring they have the capacity to succeed. Yes, provide processes, training, principles, guidelines, etc. But then focus on outcomes and accountability. And allow for learning-based corrections.

It's a radical thought, but a little anarchy may just bring the control that we need.

Here's the article about the successes of traffic anarchy...

Controlled Chaos: European Cities Do Away with Traffic Signs - International - SPIEGEL ONLINE - News

IT Architecture: Cross-Over Potential

Computer architecture principles are applied to treatment of ADHD and dyslexia with positive results. IT strategist contributes to advancement of our understanding of these disabilities. ...

... "Eugen Oetringer is an infrastructure consultant in the information technology industry. His areas of expertise include capacity management, information management, storage management, IT architecture, IT strategies, processes and complexity. He is the main inventor and author of The IT Strategy Management Process, which describes a simple way to manage important information in the midst of information overload. " ...

Root Cause Proposal for ADHD, Dyslexia, Headaches and other Conditions – Public Request for Research

Managing the Grey Areas: Lessons from the Leadership Quadrant Seminar

On November 15th and 16th, I conducted a seminar with productivity consultant Jerome Jewell called The Leadership Quadrant: 4 Ps for Organizational Excellence. The 4 Ps are Principles, People, Productivity, and Process. It was held at the National Constitution Center in Philadelphia, and we incorporated the museum’s rousing multi-media show, Freedom Rising, into the seminar.

The seminar participants came from the healthcare, criminal intelligence, and manufacturing sectors, which led to some fascinating discussion and dynamics. With any seminar, the value to all in attendance is magnified by the contributions of the participants, and this was no exception.

In the seminar, which included sections on principles, emotional intelligence, systemic thinking, talent management, innovation, project management, and more, the collective group highlighted a number of “grey areas” that a manager must frequently weigh when making decisions.

Some questions arose, such as:

"What if someone no longer likes a role they excel at and prefers a role they're poor at?"

"Do people always need to see the big picture?"

"Should one person be expected to serve the role of a manager, leader, and administrator? A strategist and tactician? A generalist?"

"How do you strike a balance between effective time management and remaining available to your staff?"

"Are recurring meetings effective or are they time wasters?"

In line with these questions, below are some of the factors that managers must consider:

• People’s individual needs vs. organizational goals
• Big picture inclusiveness vs. security (or the desire to give people narrow focus)
• Using generalists vs. specialists (and where the specialty should focus – on a functional area or on a particular skill)
• Effective time management vs. flexibility and being available to your staff’s needs
• Recurring meetings vs. consideration for people’s time
• Informing vs. influencing (for deciding whether to email or meet; even then, the decision is not always straightforward)
• Innovation vs. execution (knowing when to move from ideation to “getting things done”)
• Systemic (whole view) thinking vs. systematic thinking (routine, repeatable process)
• Vigilance vs. delegation (how much is safe to delegate, and to whom?)
• Firm principles vs. ethical dilemmas (should a firm principle ever be bypassed?)

In all of these cases, the group determined that the answer isn’t always black and white, and that each situation requires weighing these items. The trick is to observe, orient, decide and act quickly (referencing Colonel John Boyd’s OODA principle).

On the item of firm principles vs. ethical dilemmas, the group applied lessons from various cases throughout history where the US Constitution was challenged. It was obvious that there was no “one size fits all” answer.

With more recent events, consider OJ Simpson’s book. If you manage a bookstore with a principle of defending freedom of speech, do you carry O.J. Simpson’s new book, even though it is "ethically challenged," to say the least? Most large-chain bookstores creatively tried to satisfy both sides of the equation by donating all of the proceeds to the victims’ families. Of course, in the end, the book was canceled, but for a while, this was a real challenge to bookstores.

All of this reaffirms that management is abstract, not concrete. Managers cannot have all the answers; but they can and must insure that the right questions are considered, and they must have the courage to make decisions.

Extreme Project Management: Reality Rules

I just finished reading Doug DeCarlo's book, Extreme Project Management. I met Doug at a recent PMI event we both presented at. Not only is his keynote presentation a crowd pleaser (hint: he plays the drums to illustrate the pace of a typical project and uses Noah's Ark as a sample project from the "ultimate Sponsor"), but his book is chock full of practical, immediately usable ideas.

I was amazed at how much his philosophy mirrors my own, with a focus on simplicity, value, results, and the understanding that change is inevitable. A key point of Extreme Project Management is that reality rules. Plans are nice, but then results must drive further planning instead of assuming reality will yield to the plan.

As an example of simplicity, consider what he calls "The Four Business Questions":

1) Who needs what and why?
2) What will it take to get it?
3) Can we get what it takes?
4) Is it worth it?

As another example, check out his "Three Sentence Project Skinny":

1) Who will do what for whom?
2) This project will be considered completed when: ___
3) Why? This project supports the organizations objective to: ___

The book also offers handy checklists (such as what to ask the sponsor during the first and secend meetings, etc..), the 4 Accelerators, the 10 Shared Values, the 7 Win Conditions, and more.

Although the book is the size of the Encyclopedia Britannica, it's extremely readable and has diagrams that bring together all the concepts in the book. I highly recommend it to anyone looking for a book grounded in reality as opposed to academic theory. Above all, this will help project managers succeed where the rubber meets the road---communicating and dealing with stakeholders.

Amazon.com: eXtreme Project Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility: Books: Douglas DeCarlo

Principled Leadership: Giuliani

Giuliani explores presidential candidacy and fashions himself as a principled leader. Can he hold his own with Napoleon? ...

... "Leaders need to be optimists. Their vision is beyond the present, and it's set on a future of real peace and security, Giuliani said. Some call it stubbornness. I call it principled leadership. " ...

Via Yahoo! News: Link

Critical Chain again

This term's course includes the Critical Chain topic. So I'm looking around for more references and examples to illustrate the principles. This link is interesting for putting the emphasis on estimating, understanding and managing variation. Tony Rizzo, the author, goes on to examine the use of Critical Chain in a multi-project environment.
Another interesting observation is that the mainstream Project Management products do not support the approach.
The Project Management Soap Box: [17] The Critical Chain Model

Leadership Seminar: Announcing The Leadership Quadrant

For project managers looking to expand their horizons in the leadership arena, I'd like to invite PMThink readers attend an exciting two-day workshop at The National Constitution Center in Philadelphia, PA on November 15th and 16th, 2006.

The seminar, which I'm co-facilitating with Jerome Jewell of Jewell Consulting Group, is titled: The Leadership Quadrant: 4 Ps for Organizational Excellence. We're offering a $100 discount to select groups, and PMThink readers certainly qualify (plus group rates are available for parties of 3 or more).

In case you're wondering what the 4 Ps are, they are: Principles, People, Productivity, and Process. In the seminar, we'll explore topics such as Napoleon's Six Winning Principles, Systemic Thinking, Emotional Intelligence, Setting Better Priorities, Asking Better Questions, and more.

Best of all, we're incorporating Freedom Rising, the museum's acclaimed multimedia presentation, into the workshop. For details and a seminar brochure, visit the Marengo Group training web page.

21 Success Secrets of The Beatles

One thing I enjoy doing is studying excellence. There's something about unique, extraordinary human achievement that I find fascinating.

I love studying it, dissecting it, and extracting lessons from it. It's what attracted me to write about Napoleon. It's what led me to explore lessons from Einstein. And it's what leads me to dive into lessons from The Beatles.

Like them or not, nobody can argue that The Beatles didn't achieve amazing feats. I doubt there will ever be another musical group that could rival them for sheer impact on the music scene and the world.

They were the first pop artists to record in stereo. They were the first band to experiment in the studio. They were the first band to list lyrics on their album. The list goes on and on.

But what made them so successful? And are the lessons applicable to building successful and innovative individuals and teams in business? Here are 21 lessons that answer definitively "yes."

1) Focus on Strengths - They focused on their strengths, doing what they do best (songwriting and performing).

2) Engage a partner - They got help (from Brian Epstein, their manager, and George Martin, their producer). They couldn't have achieved such heights on their own.

3) Differentiate! - They dared to be different, whether it was their suits, their hair, the instruments they experimented with, their neverending search for new chords, and so on.

4) Have key values - They stuck to principle themes, such as love, peace, and the search for truth.

5) Adopt a cause - In the band and in their solo careers, they always had a cause that they were passionate about, whether peace, vegetarianism, eastern philosophy, or some other passion.

6) Worship change - They weren't afraid to change, even in the midst of success. At the top of the moptop craze, they changed their style, then they changed again with Sergeant Pepper, which was a virtual celebration of change.

7) Broaden your horizons - They continuously sought self-growth, learning new philosophies, new chords and instruments, etc.

8) Be passionate about everything you do. They treated each deliverable (i.e. song) as THE hit, which is why their "B-sides" did better than most people's A-sides.

9) Embrace conflict - They readily embraced creative conflict and friendly competition. It was precisely the conflict and competition between Lennon and McCartney that made each of them strive for new heights.

10) Keep moving - Fast! - They recorded constantly, always looking for some new and unique angle. They recorded first and asked questions later.

11) RMF (Risk Magnificent Failures) - They experimented with new chords, new concepts, and had some celebrated failures (Revolution #9-although some liked it; the Magical Mystery Tour Movie, in which they filmed everyone on a bus in the hopes that something neat would happen--nothing did). In a sense, each album was also an experiment in some way.

12) Aim for the Skies - They thought big ("To the toppermost!" they used to say) and they believed it! Similar to Napoleon Hill's principles in Think and Grow Rich, they aimed high and got there.

13) Talent matters - When all is said and done, they had the right talent. All the other elements wouldn't have helped if they didn't have a natural talent for music. Luck helps, but if you have the right talent in the right job, the luckier you get.

14) Use your whole brain - They used the left and right sides of their brain---using the right side when freeflowing creativity and innovation were needed, and the left side when the proper structure was important.

15) Have Fun!!! - Above all, they had plenty of fun, and even stressed the importance in the song "She's Leaving Home" (about a girl who left home to explore "something inside that was always denied for so many years---She's having fun, bye bye.")

16) Never Conform - They didn't conform to standard education, which led to their unorthodox style. In fact, I've noticed most great pop musicians hold their instruments "the wrong way." Tom Peters pointed the same thing out about great Tennis players and their rackets.

17) Field the right team - They were built for synergy -- each were different but shared the same values. The whole was truly greater than the sum of its parts.

18) Get noticed! - They wouldn't have gotten anywhere if they didn't get noticed in the first place. How did they get noticed? By playing in public, where they could get noticed. This should stress the importance of networking. Be seen.

19) Prototype and Test! - They prototyped and tested zillions of versions of their songs. For each hit, there were about 20 alternate takes in different styles and genres. And they practiced each version over and over.

20) Study the greats, Then forget them. - They didn't begin in a vacuum. They studied their idols, such as Chuck Berry, Carl Perkins, Fats Domino, and others. If you want to succeed at something, a good place to begin is studying those who have succeeded before. But then make your own way, just like The Beatles did. Carve your own niche.

21) Be Authentic - They were authentic to who they were - British lads from Liverpool.They could sing colorful lyrics about places like Penny Lane and Strawberry Fields, and could talk about TV shows like "Meet the Wife" ("It's time for tea and Meet the Wife" from "Good Morning"). They could sing about these things because it's who they were, not because they were trying to be cute or clever. It's important to be true to who you are, not who you'd rather be.

Project Management Texas Style ...

The plan is made. The team is resourced. The baseline is set. ... Help the team have fun and focus. ... Project management inspiration from a great coach.

... "The game planning is over and I don't need to motivate this team. My job now is to settle them down so they can relax, have fun and focus when we need to focus. They can laugh and dance in the locker room but to win we need to balance being confident and focused. " ...

Via Every Game Counts: Texas Coach Mack Brown Blogs about the 3 Things that will Determine a Longhorns Win against the Buckeyes ...

Project Results Podcast: Moral Force

Here's the latest Project Results podcast. In this podcast, I discuss moral force, the sixth of Napoleon's Six Winning Principles, which can be achieved by providing order, purpose, recognition, and rewards. Enjoy.

Soldiers and Heroes: The Right Mix is Key

Derry Simmel, who runs a compelling blog site called About PMOs (and is on the board of PMI's PMO SIG), has an interesting post about heroes and soldiers.

Soldiers, Simmel says, color within the lines and can be expected to be reliable, dedicated, and even anal at times. Heroes break the rules and tend to go their own way---they're about getting it done and getting it done fast. Damn the torpedoes.

But, as Simmell points out, an organization needs both to thrive. True, a team of all heroes can be chaotic, but a team of all soldiers will probably not bring about dramatic change.

It's all about synergy, and putting the right people in the right roles. It's also about the fine balance between exactitude, speed and flexibility (ironically three of Napoleon's six winning principles).

Building a team that capitalizes on the complementary personalities and skills of heroes and soldiers is a good recipe for success.

Here's the blog post...

All about Project Management Offices: Soldiers

Agile Project Leadership ...

Agile network sustains mission with election of new board members. I like the relentless focus on value and all of the core principles. Worth a quick check. It's valuable to anchor back to principles periodically. ...

... "Agile Project Leadership Network (APLN) New Officers and Board Members: The Agile Project Leadership Network (APLN), a partner non-profit organization focused on making people great project leaders by focusing on value, teams, context, customers, individuals and uncertainty also named several new officers to its roster. APLN was founded in 2004 by individuals active in writing about, practicing and evangelizing the movement toward fast, flexible, customer value-driven approaches to leading projects of many types. Although the organization is separate from the Agile Alliance, the group's aim is to work closely with the Agile Alliance to help them become better Project Leaders. " ...

Via Yahoo Finance: Agile Alliance and The Agile Project Leadership Network Announce New Board Members and Officers for 2006-2007 ...

The Distributed PMO: Lessons From Strange Places

I've read two pieces of information lately that couldn't be more different, and yet they both got me thinking about the benefits of what I call a "distributed PMO."

First, as I mentioned last week, I had read about Ken Kizer's magnificent transformation of the formerly abysmal Veteran's Health Administration (a poorly run group of hospitals mired in government hierarchy and bureaucracy). He established an network of regional "hubs" (what he called Virtual Integrated Services Networks, or VISNs - pronounced "visions"). Each VISN was itself a network of partnerships, associations, alliances, hospitals, etc. that worked together for the good of the customer.

The VISNs had the benefits of standardized quality with local presence. Decision-making was moved from Washington HQ to the VISNs, who were closer to the action than Washington HQ could ever be.

The role of headquarters became one of support, guiding principles, consulting advise, information services, and change leadership. Headquarters drives behaviors that benefit the overall structure.

Forms and approvals were reduced to a bare minimum. A relentless focus on the customer/patient (one of my battle cries, as most of you know) now guides all decisions and research.

If this isn't a good model for a PMO, I don't know what is. If project managers and functional experts (each who rely on one another for success) operated in various "regions" and/or functions (close to the action), and the PMO's role were to provide (and I repeat from above) support, guiding principles, consulting advise, information services, and change leadership, more PMOs would become a valued and integrated part of their organization.

And if the focus were on reducing forms and bureaucracy, helping project teams be successful, and improving the customer experience (as opposed to an internal focus on merely schedule and budget metrics), PMOs might find themselves more popular as well.

Incidentally, this also happens to mirror the Toyota organizational model.

The idea of a distributed, integrated network isn't unique to business. It even happens in nature (here's where the strange part comes in). I was reading about a giant sea creature, larger than a blue whale, called a Giant Siphonophore (Praya sp.). The creature (yes, this is true, folks) runs 130 feet long and is actually made up of many other life forms, each having its own specialized role that works to service the whole entity, yet is unable to exist on its own. In other words, the Giant Siphonophore is a "colonial life form." As I read this, I was again reminded of the concept of a virtual, yet integrated network.

Yes, I actually make these odd connections, but ideas can come from anywhere. By the way, the creature can be seen in the IMAX film, The Living Sea (available on DVD). Here's more info on the colonial nature of the Giant Siphonophore and it mutually dependent parts. Food for thought.

Is the Role of the Project Manager in Jeopardy? - An Editorial

A few weeks ago, I posted a blog about the new Program Management credential from PMI. In it, I referenced PMI's definition of a program manager vs. project manager in their FAQ page.

A project manager, according to PMI, has the following responsibilities (I've put some of the key points that jumped out at me in bold):

• Perform their duties under general supervision and are responsible for all aspects of the project for the life of the project
• Lead and direct cross-functional teams to deliver projects within the constraints of schedule, budget and resources
• Demonstrate sufficient knowledge and experience to appropriately apply a methodology to projects that have reasonably well-defined project requirements and deliverables.

A program manager, according to PMI, has the following responsibilities (again, I've bolded the key points):

Under minimal supervision, program managers are responsible and accountable for the coordinated management of multiple related projects directed toward strategic business and other organizational objectives. These programs contain complex activities that may span functions, organizations, geographic regions, and cultures. Program managers build credibility, establish rapport, and maintain communication with stakeholders at multiple levels, including those external to the organization.

Clearly, a program manager must be closely tied to the strategic goals and benefits, monitor the program accordingly, and have a strong connection to senior management. And I also feel that the new credential seems on the surface to set the bar appropriately high.

But I can't help but feel that, in contrast, the PMP credential is losing steam. First, there are myriad organizations virtually guaranteeing an "instant-PMP" after a crash course and some tweaking of one's background experience (although PMI is now doing audits of work experience).

Second, a project manager must, in many cases, go beyond the PMP/tactical focus and possess the same traits and skills that PMI has designated as requirements of a program manager, especially in the case of an enterprise and/or global project, such as a business transformation effort. I realize PMI's role definitions are a way to differentiate and justify the new certification and I suppose one could organize their effort into a "program" to qualify for that certtification, but in these changing times (and with greater challenges for project managers), I think PMI needs to evaluate and revamp the PMP certification as well.

When I do presentations on principle-based leadership training, I have a slide where I present what I call "The PM Challenge." I present it as a boxing match. In one corner, we have a project manager, armed with MS/Project and the PMBOK, but lacking:

• Business Acumen
• Leadership Skills
• Conflict Management Skills
• Negotiation Skills
• Presentation Skills
• Communication Skills
• Strategic Intuition

In the other corner, we have the "challenger," represented by "the project," with the following characteristics:

• Global, virtual team
• Complex technology
• Complex change
• Multiple vendors
• Offshore resources
• Conflicting Stakeholders
• Scrutinizing Executives

Such a project manager, without the appropriate leadership and soft skills, doesn't stand a chance. Wouldn't a person with the skills PMI describes as a "program manager" be more apt to have success?

In the latest PM Network magazine from PMI, there are not one, but TWO articles that illustrate this point. One is titled "Project Management 2.0: Project Management is at a Crossroads," by Peter Fretty. The other is titled "No Limits," by Marcia Jedd, and talks about what project managers must do to crash through the glass ceiling and elevate it from the tactical trenches.

Perhaps a start would be to take a new view of project management beyond just "executing to a set of requirements to deliver on-time and on-budget." The current tactical focus might explain the consistent failure rates of projects. One problem is that PMI has traditionally "followed common good practices in the field," which of course is what a standard is supposed to do. The problem is that common practices have brought common results, which aren't all that good. Time for an upheaval. Perhaps they need a section, apart from the "standard" itself, for "new frontiers in project management," which could outline those who are breaking the mold with good results.

I'd be interested in others' thoughts on this topic. Who knows---It just might help drive requirements for the next version of the PMBOK and/or PMP credential.

Implementing PPM: Don't Expect Overnight Results

Karen Klein of Projects@Work interviewed Daniel Stang, a principle analyst at Gartner, on preparing for Project Portfolio Management (PPM).

Some key lessons are to not expect overnight success, to implement in stages (beginning with automating what is already working), and to engage a good change management team.

Organizations that attempt to go from zero to high level maturity via a big-bang approach run a high risk of failure. Stang also cautions against trying to sell PPM initially on the hard benefits. The benefits at the early stages of maturity tend to be softer, with the tangible benefits coming later.

Here's the article. Also, see the free PPM Software Evaluation tool offered at the bottom of the article.

http://www.projectsatwork.com/content/Articles/232143.cfm

June Podcast from Jerry Manas - Simplicity

OK, so it's already July, but better late than never.

In this month's podcast, based on Napoleon's "Six Winning Principles," I discuss the importance of Simplicity, and how to achieve simple objectives, messages, and processes. I also explore Napoleon's personal system of time management and record keeping.

IT Strategy: Customer Focus SOPM ...

Marc Puich discusses the opportunity for information technology in the biopharmaceutical industry, advocating a simplified enterprise application architecture and a gradual, disciplined approach to operations excellence. I especially like his thoughts on customer focus and feel this spirit should be reflected in the principles of the service-oriented project management methodology that we are developing. SOPM should be customer-centric and its critical path should focus on the essential deliverables for customer success. ...

... "Begin with the customer. Developing an IT strategy should begin with an external focus. This process requires taking a critical look at what functionality is truly necessary to support your customer, versus what would be nice to have. The goal of a system is not to remove people from a process, but to provide the customers with what they need. " ...

Via BioPharm International: Operations Excellence: Perfecting IT Management System Selection for Biopharmaceutical Organizations - Proper application of an IT system can be a critical component to driving efficiency and reducing waste ...

Software Selection Process; Everything You Need to Know

There's a good writeup on ProjectPerfect offering guidelines and principles for selecting software---from the gathering of internal support through the evaluation and selection process itself.

It's definitely a valuable read for anyone involved in the software selection process.

Here's just a sampling of some of the great tips in the article...

• Tell the vendors at the start what the process for selection will be. They will appreciate knowing what the path is, and how you will reach a decision. It assists their planning as well. You will get far better service if they know when you are going to make a decision.
• Consider an external person to do the negotiation. If negotiations are tough and the vendor feels they have been squeezed dry, it is better for the person who did the squeezing to be gone so that there are less lingering traces of animosity.
• It is a bit like herding cats but you need to keep a single point of contact with each vendor. If vendors can see a chance to influence people at different levels you will soon find all sorts of pressures being applied to you.
• Treat it as a team selection decision, and make sure your team know the process. If you set the path and the criteria from the start, it will help manage expectations internally.
• It is useful to get written agreement from each vendor to comply with the process as a condition to being considered.
• Beware the trap of having their top technical person available all through the sales cycle only to be replaced at the point of implementation by someone who has been with the company for a week. If the vendor is also involved as an implementer, have the implementation team named in the contract.
• The purchase process should be costed into the budget just as the cost of the software and implementation are costed. There can often be many man months of effort required to manage the process and, if not done effectively, will cause major cost blowouts when the wrong software is purchased.
• Another factor touched on a number of times is that much of the work is sequential. There will be gaps in the process – for example between requesting a demonstration, and organising the people to participate. During that lull in proceedings, other work can be done that will contribute to later activities. A software purchase can result in a very complicated schedule.

Here's the full article...

A Software Purchase Process

CIO Drives Enterprise Architecture Standardization and Best Practices: A Common Theme ...

CIO drives standards and best practices to moderate IT spending to acceptable percent of sales. A recurring theme. Where's the innovation or differentiation? ...

... "In terms of governance and best practice that means things like the introduction of the Prince 2 project management principles, IT information library (ITIL) guidelines for IT infrastructure and BS7799 certification for security. " ...

CIO Drives Enterprise Architecture Standardization and Best Practices: A Common Theme: Via silicon.com: United Business Media CIO Matthew Graham-Hyde ...

Join the Project Management Revolution; The SOPM Model Takes Shape

OK, I've been fleshing out the Service-Oriented Project Management (SOPM)™ model, and have come up with a more memorable and catchy representation of the four steps, although the actual content is pretty much the same.

The acronym for the four phases is UP-IT (which can symbolize "upping" the level of customer service, saying "up yours" to old ways of doing things, or "upping" the success rates of IT projects---in which case the "it" stands for "IT").

Ready??? Drum roll please......

The four phases are:

• Understand
• Prepare
• Iterate
• Transform

Here's a revision of my previous post on the topic...

1) UNDERSTAND ... Develop an understanding of the problem being addressed, the goals, constraints, the internal environment, the external market, benchmarks, the people and subject matter involved, potential solutions, risks, benefits/justification, and any other knowledge necessary for success. Most of all, understand the customer and what they need to be successful.

2) PREPARE ... After helping the customer obtain approvals if needed, prepare the project organization (resources, roles & responsibilities), operating principles, the infrastructure and tools needed to run the project, organizational alignment, preliminary training needed, communication, and anything else needed for a smooth road ahead.

3) ITERATE... Using the axiom, "Think bold, implement safely," plan, design, build, test and pilot the solution before attempting a full scale implementation. Encourage innovation. Implement in phases to achieve quick wins, earlier benefits, and greater customer satisfaction. Consider iterative prototypes during the design phase. Don't forget additional training needed.

4) TRANSFORM... After each project phase and at the end of the project, evaluate and document lessons learned, customer satisfaction, and benefits achieved (vs expected) for the purpose of transforming yourself and the customer for the better. This includes guiding the customer to help them achieve maximum results with the product or service delivered, and laying the groundwork for their continued success.

Now that I have the framework locked in, I'll complete the model around these four phases. I am absolutely convinced that this model can help increase customer satisfaction and the general success rates of projects.

May Podcast from Jerry Manas

In this month's podcast, I discuss the importance of Flexibility (the 3rd of Napoleon's Six Winning Principles), and how to insure that your teams are adaptable, empowered, and unified.

SOPM; A New Project Management Methodology

Service Oriented Project Management (SOPM) is taking shape as a methodology that fills the gaps in traditional project management, namely a RELENTLESS customer focus and the all-important analysis and benefits evaluation after the project has "completed."

As I fine tune the model, I'll post the iterations here, as a methodology in progress.

The four high-level steps in SOPM are as follows:

1) UNDERSTAND ... Develop an understanding of the problem being addressed, the goals, constraints, the internal environment, the external market, benchmarks, the people and subject matter involved, potential solutions, risks, benefits/justification, and any other knowledge necessary for success. Most of all, understand the customer.

2) ENABLE ... After helping the customer obtain approvals, prepare the project organization (resources, roles & responsibilities), operating principles, the infrastructure and tools needed to run the project, organizational alignment, preliminary training needed, communication, and anything else needed for a smooth road ahead.

3) ITERATE... Plan, design, build, test and pilot the solution before attempting a full scale implementation. Implement in phases to achieve quick wins, earlier benefits, and greater customer satisfaction. Consider iterative prototypes during the design phase. Don't forget additional training needed.

4) EVALUATE... After each project phase and at the end of the project, evaluate and document lessons learned, customer satisfaction, and benefits achieved (vs expected). This includes evaluating how the customer can achieve maximum results with the product of the project, and laying the groundwork for their continued success.

By using an UNDERSTAND, ENABLE, ITERATE, and EVALUATE process, with COMMUNICATE as an overarching activity that extends across all four steps, we adopt a much more holistic and customer-centered approach to project management.

A few key points... Customer satisfaction should be measured at milestones throughout the project, not just at the end. It's as important as monitoring cost and schedule (i.e. Earned Value performance).

Imagine seeing an S-Curve showing Planned Value, Earned Value, Actual Cost, and Customer Satisfaction. Maybe your project is on schedule and on budget, but the customer isn't satisfied with the results (or with the project communication, or a whole host of other issues).

A narrow focus on cost and schedule takes too much of an inward view. Besides, measuring customer satisfaction throughout a project allows for corrective action instead of managing in the rear view mirror.

More to come.

NOTE: I have since revised this model. See my updated entry.

Service Oriented Project Management (SOPM); Bridging Three Worlds

With all this talk about Business Process Reengineering (BPR), and the latest industry focus on innovation, I've been piecing together a model that brings together the best of BPR, Innovation, and Project Management (and even borrows elements of ITIL). I call it Service Oriented Project Management or SOPM. I believe the term has been used, but not in this context, and not as a formal model. I think it's important enough that it needs to be formalized.

There are some that view these three disciplines as separate, or even mutually-exclusive, but they're not. In fact, to be successful, these disciplines need each other. It should go without saying that BPR needs innovation in order to break new ground (resulting in dramatic and radical change, as opposed to incremental change). And project management skills are needed to keep a team on track and manage risk.

Certainly, there are situations where incremental change is quite appropriate, and, for these cases, process "improvement" disciplines such as Six Sigma and TQM are fine. But especially when radical change is needed, we need a superstructure of good project management to lead all phases of a BPR initiative, from the as-is state exploration, through the to-be state development and validation, and to the actual implementation of the initiative.

Likewise, project management in general needs the strong customer focus that BPR brings (usually sorely lacking in most projects). Almost any project can benefit from a BPR-type approach of getting to the root of the customer's problem first-hand, and bringing about dramatic results through innovative thinking. This also takes project management beyond the realm of simple "execution and control".

Using a BPR lifecycle, innovative thinking, and an overall project management approach, we get a holistic methodology that uses the best of each. And, if this is driven by overarching principles from all three disciplines, we can boost our chances of success exponentially.

And finally, there's the customer. EVERYTHING in all of these disciplines must have a relentless focus on the customer. With any initiative, the glue that holds all of this together is a service owner--- someone who understands the customer's needs (and their business) and owns the initiative from cradle to grave (just like an ideal order fulfillment process should be, according to Michael Hammer, the inventor of BPR). Whether or not this should be the project manager is a whole subject in itself, but it should be someone.

If the project manager does assume this role, then they had better have a strong customer and business focus, and be relieved of any project administration duties that aren't adding value to the customer (which can be assigned to a project accountant). In many companies, the project managers may not have the right skills for this role, but that's not to say that shouldn't change.

More to come, as I flesh out and develop the model. Meanwhile, I'm open to your thoughts on this.

April Podcast from Jerry Manas

In this month's podcast, I discuss the importance of speed, and how to balance it with adequate planning.

Learn what can happen with even the slightest delays, as well as how to reduce resistance, increase urgency, and focus your resources.

Speed is the second of Napoleon's Six Winning Principles that I cover in Napoleon on Project Management. Last month, the topic was Exactitude.

Software Projects Doomed From the Start; Blame the Stakeholders

OK, maybe this doesn't top the skateboarding dog (see yesterday's post), but here's an extremely compelling article from the Defense Acquisition University (DAU) on why most software projects are doomed to failure.

Thanks to PMForum for posting this in their news section.

The article states that most software projects come nowhere near their original baselines (although they may come closer to approved revised baselines). It says that stakeholders and the organizational environment, more so than lack of project management skills, bear much of the blame. Here's a quote:

"No amount of training in the technical skills of program management will overcome the simple truth that, as a PM, you cannot make people do what you need them to do. This is the root cause of many software-intensive program failures. Stakeholders often cannot agree on priorities, refuse to standardize business practices, take off on their own proprietary solutions, or simply refuse to participate in the program."

The article also says that the original plans are usually unrealistic to begin with, and underestimate the organizational challenges. It says we make matters worse by holding project managers accountable without giving them the necessary support to be successful.

"... Most expectations of contemporary programs are unrealistic. The cruel reality is that we train PMs and drop them in an organizational 'shark tank' that opposes many of the principles they have just absorbed in their training. Program managers often find themselves in a superfluous role, accountable, yet powerless. "

The article proposes a system of observing stakeholder behavior and rewarding and discouraging behavior as appropriate. Of course, an organization must recognize the problem and commit to doing something about it.

Senior leadership must be actively involved in fostering the changed behaviors. Otherwise, software projects will continue to be underestimated and mired in conflict, despite the best training, the best EPM tools, and the best processes.

I highly recommend reading the full article, "Irreducible Truths of Software-Intensive Program Management", by David Cottengim.

PMFORUM, Connecting the World of Project Management PMFORUM Breaking News: MOST SOFTWARE PROJECTS ARE DOOMED TO FAILURE ACCORDING TO PENTAGON PAPER

Jerry Manas March Podcast - Exactitude

In this month's podcast, I discuss the first of Napoleon's "six winning principles" - Exactitude (based on the book, Napoleon on Project Management).

Project Management Presentation In a Box

From BVBA out of Belgium comes a website with some useful presentations for sale. If you ever have to give a presentation on project management, either for training, consulting, or general awareness, BVBA offers a 151-page powerpoint presentation for $80, which can be downloaded and tweaked as needed.

For a mere $80, it can save quite a bit of preparation time. I took a look at the sample slides, and it takes a good approach and covers some proven principles--not just "how-to" information. I like the slides on positioning a project for success, etc.

The site offers other templates as well.

Project Management Templates. Free Risk Forms

How to Institute Good Values in 8 Easy Steps

I've been reading Leading With Values, a booklet from Bud Bilanich, AKA The Common Sense Guy. Although it's a mere 48 pages, it's chock full of useful advice on how to institute values in your organization or team.

Here are Bilanich's "8 Common-Sense Leadership Strategies for Bringing Organizational Values to Life" -

1. Develop a personal understanding of, and committment to, your organization's values.
2. Use this understanding and commitment to become a values role model for your people.
3. Communicate values as expectations.
4. Become a teacher; ask questions; show them how.
5. Minimize/remove the obstacles, or help people work around them.
6. Provide recognition to employees who bring the organization's values to life.
7. Redirect team members who are out of sync with organizational beliefs and principles.
8. Never give in or give up; set the tone and don't give in to pressures or obstacles.

Sounds like common sense to me!

Projects@Work Interview- Sacre Bleu! Napoleon, Project Manager?

For those curious to learn more about my upcoming book, Napoleon on Project Management, I was fortunate enough to be interviewed by Karen Klein at Projects@Work about it.

We spoke mostly about the "six winning principles" that led to Napoleon's extraordinary accomplishments, and the "four critical warning signs" that we should all be aware of to avoid meeting our own Waterloo.

Also cleared up a few popular misconceptions. For more, here's a link to the interview...

http://www.projectsatwork.com/content/articles/229826.cfm

Business Process Governance: Setting Priorities ...

The convergence of benefits realization from ERP implementations and the drive towards operational excellence have placed IT at the epicenter of business process transformation. Good governance can ensure the leadership committment and focus necessary to achieve real change. Andrew Rowsell-Jones, Gartner, extends the approach for IT governance to the enterprise decisions necessary to drive enterprise transformation. ...

... "Process governance can be defined using the same tools for defining IT governance - but extended to include decisions about process priorities. These additions include the principles used to govern decisions about processes, and benefits realization, where C-level executives and at least one other business group, plus the CIO, have to call the shots. " ...

Business Process Governance: Setting Priorities: Via CIO: Change Is the Name of the Game ...

Why Projects are Late; The Top Six Reasons

Here are the top six reasons why projects are late and what we can do about it...

1) Unrealistic Deadlines - As we've reported here before, this is one of the most frequently overlooked reasons for late projects---and unfortunately, often the last thing people look at.

Solution: It's imperative for a project manager to defend the right plan and not give in to pressure to sacrifice good principles. If necessary, negotiate to time-box the project into multiple phases.

2) Customer/Partner Availability - I've seen numerous project managers over the years talk about the challenges they face keeping a project on schedule when they're waiting on a customer or business partner to do testing or sign off on some deliverable.

Solution: Set milestones, monitor progress, and raise an issue if the lack of availability will cause a delay. If necessary, negotiate a new project baseline---which may be quite appropriate if the customer and/or steering team agrees that a delay is acceptable.

3) Resource Availability - There's nothing worse than putting together a reasonable schedule only to have your key resources pulled off into different directions, but it happens more often than we care to admit.

Solution: Try to obtain full commitment up front for your resources' time. Even so, unexpected conflicts will happen. Same as #2 above, set milestones, monitor progress, and raise an issue if needed. Again, negotiation may be necessary, which can result in getting your resources back or in setting a new project baseline to accommodate the new priorities.

4) Uncertainty - Especially in the IT field, uncertainty is a given. At any time, unexpected circumstances may cause project delays.

Solution: Use rolling wave scheduling, planning the whole project from a high level, but only the nearest 90-day horizon in detail. Try agile approaches as well, aiming for prototypes and frequent iterations. Ideally, pilot the project, and aim for vertical rollouts (one group at a time). Build contingency into your schedule for known risks. Most of all, manage stakeholder expectations.

5) Management Decision - Sometimes, management makes a conscious decision to delay a project, either for strategic needs, changes in priorities, or any number of reasons.

Solution: If the delay is a management or customer decision, a new project baseline should be saved, with current metrics based on that. Note that it's also important to keep the original baseline, as that offers a different set of measures (mostly around organizational alignment).

6) Poor Estimates - Sometimes a project is late simply because tasks were underestimated or omitted from the schedule. Although this is not always the cause of project delays (and rarely the only cause), it tends to be the first one people look at.

Solution: Build experience and capture historical data by project category and activity. If the data isn't categorized it won't be useful. Create and maintain checklists of items to consider. Build project schedule templates. The most frequently overlooked areas in IT are: training, data-loading, cutover preparation, system network testing, adequate QA testing, and documentation.

Learning from Project Experience

In the continuing quest to learn from others' experience, this paper came to our notice. It is interesting for many reasons, not least because this was definitely not a high tech project. The fact that it was a community project adds extra relevance to the principle that beneficiaries are stake holders too. Thed three main lessons reported were the need for beneficiary involvement, missing a requirement for solution flexibility in the requirements statement and not learning from other projects.
This last item calls to mind a curious bit of selective blindness that often afflicts pilot projects. That is the absence of metrics built in to the design of pilot projects - so no formal means of determining whether a pilot was a success or not.
India - Learning from Experience in India's Watersheds

Enterprise Architecture: Operating Principles ...

Tony Young, CIO Informatica, shares his thoughts on developing an enterprise architecture in a mid-size firm, by building on a foundation of business alignment and operating principles. ...

... "Establish your guiding IT principles. I hosted a half-day meeting with the five brightest minds in IT to identify the linkage between the business drivers and goals and our own IT principles. Limit these principles to roughly a dozen; any more gets overwhelming. One of ours, for example, was - all applications must support single sign-on via Microsoft's Active Directory Services. " ...

Enterprise Architecture: Operating Principles: Via Search CIO: MIDMARKET CIO BUILDS BIGTIME EA ...

Podcast: The 3Ps of Project Success

In the first of what will be a monthly podcast, Jerry Manas, author of Napoleon on Project Management and co-founder of PMThink!, speaks about the 3Ps of Project Success: Principles, the Past, and People.

Scrum: Microsoft Adopts For Project Speed ...

In keeping with our scrum theme, this method focuses on delivering value early in the product lifecycle. Simon Avery reports on Scrum software development method employed by Microsoft to accelerate new product cycle time to market. ...

... "To get its classified system to market as fast as possible, Microsoft is relying on what it calls the scrum method of software development, which involves a very small team of engineers. For the on-line classified product, code named Fremont, there are just six developers. " ...

Via The Globe and Mail: Executive Decision: Classifieds force sluggish Microsoft to scrum

Additional resources on Microsoft and scrum ...

Via Microsoft: Download details: Project 2003 Tool: Scrum Solution Starter: "Scrum is an Agile project management practice that employs short iterations and continuous improvement. The Scrum solution starter extends Microsoft Office Project Professional 2003 or Project Standard 2003 and enables project managers to perform basic Scrum work. "

Via Chris Flaat's WebLog : People are not fungible resources: "We are currently using both Scrum and more traditional project management on several efforts going on within our product unit, and I thought I'd share some learnings. Something we're running into is that getting people dedicated to one effort can be hard, depending on the management style of the relevant managers. "

Software Tools and Methods: "This presentation started with a brief context-setting look at why Agile approaches are gaining in popularity. It then discussed the fundamental principles that are common to most Agile methods, and used the Scrum approach to give a more detailed view by example on how Agile projects work. "

Scheduling is Dead, Bring on Chaos; So Says A Foremost Scheduling Expert

Project scheduling has no future whatsoever, and this comes from no less than Murray Woolf, the Managing Director of the PMI College of Scheduling's Scheduling Excellence Initiative (SEI).

This article, posted at PMForum is one of the better ones I've seen in a while (possibly because it's aligned with my philosophies). The premise is that, in today's day and age, the industry is headed toward more of a "give the people objectives and let 'em work it out" philosophy, which is completely opposed to the old "build a detailed schedule and make 'em follow it" mentality.

This is completely aligned with a value system that I've long subscribed to (and had posted on here at PMThink), and that is: To foster passion and accountability, we need to provide:

- Autonomy and Trust
- General Guidance and Principles
- Support and Removal of Barriers

This, of course, must be supported by having clear objectives.

Through all this, we also need to send a message that results are more important than blindly following rules. This doesn't mean that we needn't have processes, as people need a system in order to achieve consistent results; merely that we should give project managers the freedom to bypass certain processes if it's necessary to achieve good results. "Good" is the operative word here. Just meeting a date is not "results."

I believe that Mr. Woolf's article endorses my approach, and acknowledges that the following is where the future of project management is:

More organized chaos than it is controlled components.
More project facilitation than it is project scheduling.

This doesn't mean that planning isn't important either; merely that the act of planning shouldn't be confused with rigidly following the plan/schedule. As Dwight D. Eisenhower said, "Plans are nothing; Planning is everything."

As it is, and as Mr. Woolf rightly points out, project managers and "schedulers" are so bogged down in details and administrivia that they become more project reporters than managers. We need to observe where the future is headed and free project managers from the burdens of such fruitless details.

Instead, their efforts should be spent on adequate preliminary research, communication, facilitation, risk awareness, and other traits necessary to effectively manage a project.

For the full article, which I highly suggest reading, see Mr. Woolf's paper below...

PMFORUM, Connecting the World of Project Management - Papers

Project Failure Rates Soar; Blame the Estimates

How many times have you heard these statements from management?

"I didn't call this meeting to discuss whether we can meet the deadline. We're here to decide how we're going to meet it."

"What we've got to do now is to roll up our sleeves and do whatever it takes to get the job done!"

"I agree with you in principle, but this project is so urgent that we just don't have the luxury of doing it right."

These statements are all referenced in an excellent article by Conrad Weisert, titled "The Burden of Proof in Estimating." He attributes it to the fictional "Management By Cliche Handbook," but the statements and the poor results they usually lead to are anything but fiction.

With project failure rates not much better than they were five years ago, this article validates what I've been saying for a while: Most projects that run over budget do so because the original unrealistic estimate was provided under pressure from management.

It's critical that a project manager defend the right plan and negotiate tradeoffs in scope, time, or cost accordingly. Perhaps the best approach, and most consistently effective one, is to timebox the scope, aiming for realistic, phased deliverables.

It's also important when submitting a budget estimate, that the correct level of accuracy is stated (i.e. plus/minus 25%, or whatever is appropriate). PMI offers some guidelines, but those are just that---guidelines. A detailed bottom-up baseline estimate should only be provided after a detailed schedule is developed.

The bottom line is this. Weisert has a very simple principle: "In assessing the credibility of a project estimate the burden of proof falls on those who claim it can be done." This is sage advise. For the full article, read on...

Burden of Proof in Project Estimating

Project Management Competency; Using the Learning Ladder

I was recently reading Peter Fogel's If Not Now, When, a humorous book about reinventing yourself, and he referenced the four stages of learning any new skill. It reminded me how valid this is in organizations trying to implement project management.

I've seen these stages also referred to as the "learning ladder" or "The Four Stages of Competence." It's not clear who created it. Some sources date it as far back as Socrates or Confucius, but its modern form has been in psychology books since the 80's.

The four stages are as follows (I'll paraphrase the explanations):

1) Unconscious Incompetence - Eveyone knows you're clueless except you. You don't realize why or when you're not achieving results, and are surprised when people complain.

2) Conscious Incompetence - The light bulb goes off. You suddenly "get it" and realize you need to do something different. You begin taking actions to change.

3) Conscious Competence - You're becoming more confident, and accomplishing goals through checklists, reading, learning, and mentoring. Things don't feel totally natural yet, nor should they, but you're achieving small successes.

4) Unconscious Competence - This is the ultimate goal. Some call it situational awareness. The French call it coup d'oeil. It's like riding a bike or driving a car, and only happens with adequate experience, and some trial and error.

This is funny, but very true---perhaps still the best example of a maturity model I've seen to date. Unfortunately, many organizations think they can mandate this fourth level. The fact is that it can only be reached by progressing through the paths above. You can't just jump levels, although good principles and an adequate support system can speed the path forward.

The bottom line is that we must allow time to progress through the levels and not criticize too harshly. Secondly, we must seek ways to provide principles and support to ease the transition through these levels.

Criticism is not the way to promote maturity. More on this coming up...

Results vs. Process - Revisited

The other day, I posted a blog on results vs process. The conclusion I came to was that for projects (which are by nature of limited duration), it was more important to do what it took to assure good results than to blindly follow process.

Of course, the definition of "good results" must be agreed upon. I also added the caveat that this does not apply to processes that must be observed to assure adequate results.

While I still fully believe this approach is true as a guiding principle for project managers, I've come across two good arguments in defense of process in general:

1) Results are often uncontrollable, while processes (if maintained) can at least assure more consistent results over the long haul. Uncertainty is a given, and good processes will allow for that and plan for that.

2) Conflict should always be expected, and should be used to improve processes rather than be seen as an impediment to results. Conflict is a good thing. Unresolved conflict is not.

My clarification of "results over process" is this:

• When defining processes, don't make the processes so heavy and bureaucratic that they impede results.
• Introduce processes slowly. Don't expect overnight results; Follow a maturity model and strive for continuous improvement.
• Relentlessly search for less invasive ways of accomplishing control.
• For each potential new process, use the"Five Why's" (asking "why" five times until you determine if the process in question is really needed). If in doubt, don't add it.
• Allow room for people to make decisions. If a principle will work just fine to help keep people on course, then don't institute an unnecessary process. Not everything can or should be "process-ized." Generally, aim for principles over processes wherever possible.

I do think Toyota has it right. By focusing on long-term results (i.e. continuous improvement) over short term results, continued success is more assured. By we don't want to unnecessarily impede short term results either. We can walk this balance by keeping our processes lean and giving project managers the freedom and confidence to do what is right to successfully deliver a project. People are ultimately our best asset.