Leaders Create Purpose by Engaging Stakeholders

Change professionals ...

ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch ch

... offer their prioritization of critical success factors when managing change. ...

... "Leadership, Purpose and Stakeholder engagement were consistently ranked as the most important factors. " ...

Via Houghley Ltd: Successful Change

Total Project Costs Driven by Training and Change

Health record implementation incurs significant costs related to organizational change, required to train users and sustain their processes during the transition. ...

... "Training and related productivity losses represent more than 50% of the total cost involved in a big EHR project. " ...

Via Health Data Management: Kaiser Permanente

Project Pain is Indicator of Gain

Leading CIO embraces pain as evidence of positive transformational impact. ... ie: improvements in process capability and maturity will cause setbacks and discomfort. This leadership acknowledges and embraces this reality upfront in the project principles. ...

... "Our business processes and practices will change significantly, and we will accept some disruption to achieve the ultimate benefits. " ...

Via Information Week: Acknowledge Transformation Challenges

Embrace and Enable Continuous Change

The following article discusses an approach to position an enterprise for successful change. Change is a constant part of what we do, in the project management space, and the pace of business change will only continue to accelerate in the future. This reminded me of the kaizen methods of continuous improvement, that are the foundation for the Toyota production system and company culture. A fabric or mechanism for continuous change, even small changes, builds an organizational competence that can scale. ...

... "In order to take advantage of the improvements or avoid the disruptions, a mechanism needs to be built into the fabric of the company to make change part of everyday work life. When this mechanism is built into the company, the introduction and acceptance of change becomes a lot smoother. " ...

Via TechRepublic: Built-in change processes

Document Project Portfolio Moves

Document your project portfolio changes --- in-summary on the portfolio dashboard and in appropriate detail in offline documentation --- so you have a reference to your history. ...

... "At some point in the future, you may find this decision to be called into question. Even if the decision wasn’t yours to make, you may find yourself asked why Project X was ever shut down. " ...

Via Baseline: Pulling the IT Project Plug

Change Projects

IBM study validates the challenges associated with change projects and identifies actions that differentiate the leaders. ...

... "Rather than simply throwing money at the problem they invested in building awareness of project complexity, spending more on building change skills and developing their long term tools, methods and capabilities. " ...

Via IBM: Organizational Change Projects

Business Process Modeling Projects

Bill Gates reflects on the future and sees business process modeling and process change maturing significantly. ...

... "Really modeling the business where you can actually see schema models that really let you understand what's going on in your business and . . . change those models without having to go back and have some two-year IT project to do it, that's probably in the 10-year time frame. " ...

Via Computerworld: Bill Gates Crystal-Ball

Packaging ReThink

Packaging redesign increases energy efficiency, operational efficiency and asset utilization with some degradation in customer usability. Stores offer change management to customers in order to ease the transition. Expect more of these changes as the new reality of energy and fuel costs drives industry actions. ...

... "The company estimates this kind of shipping has cut labor by half and water use by 60 to 70 percent. More gallons fit on a truck and in Sam's Club coolers, and no empty crates need to be picked up, reducing trips to each Sam's Club store to two a week, from five - a big fuel savings. " ...

Via NYTimes: Green Milk Jug

Driving Solution Adoption after Project Go-Live

Are there parallels between project delivery / benefits realization and the behavior of the market under bear conditions. Contrarians begin to notice when to make an investment. And, eventually the herd turns and the market moves. Can we learn from this phenomenon and translate into the project space? ...

... "Researchers who study nonconformity, fads, even game theory, agree that in any declining market, investors will inevitably begin to bet against the behavior of the herd. Many of these initial contrarians may be working from their own analyses ... " ...

Via New York Times: How to Turn a Herd

Adoption Risks with Innovation Projects

Whether you are implementing a fundamental new innovation or providing a new way to do things, cultural adoption is a risk you can't overlook. Considering your change management strategy? Do you promote methods that drive addiction or use Frankenstein to your advantage? Read on for some insights. ...

... "Great innovations have foundered over human stubbornness. ... Resistance to technology is an omnipresent risk for every innovator. " ...

Via New York Times: Risk

Project Advice for 2008

Advice for the new year includes building better business cases and planning for the organizational changes needed to operate new business processes enabled by technology implementations. ...

... "If your business case can't stand up to careful scrutiny and evaluation, then it's highly likely the project will experience significant downstream problems. " ...

Via ZDNet: Five Tips for IT success in 2008

Agile Scrum Concepts Discussed

Ken Schwaber, the original scrummaster, visits the Googleplex to discuss agile techniques. ...






The Agile Alliance

A Goose Learns to Lead: Meet Gregory

I just returned from a mind-altering three-day thought leadership summit in Connecticut, hosted by Judith Glaser, author of Creating We and The DNA of Leadership (both of which are landmark books for leading change and ensuring alignment in your organization or team).

At the summit, which we collectively titled The First International Creating We Summit, we engaged in deep conversation and shared the most groundbreaking tools for facilitating real change. Present were the leading thinkers from a variety of disciplines, including organizational development, neuroscience, psychology, and more. The mutual benefits and shared learnings were so great that we realized we need to keep working together on an ongoing basis.

Rest assured, more will come from this, so stay tuned. Meanwhile, we got to preview a new video from Judith Glaser, called The Leadership Secrets of Gregory Goose. Don't let the title, or the simplicity, fool you. This animated short packs a wallop in its short 6 1/2 minutes, and is bound to generate discussion among leadership teams who watch it. The purpose of the video is to help leaders understand how sharing power releases the leadership instincts in others.

Here's a brief snippet, along with information for ordering it (the package comes with a facilitators guide and power point presentation, so you can conduct your own workshop with the video). If you order it, tell them PMThink sent you.

The Leadership Secrets of Gregory Goose by Judith E. Glaser :: Benchmark Communications, Inc.

Engage Stakeholders for Project Success

Some tips on positioning a project for success, including video insights. ... Have you identified your user community? Will you need super-users in the community? How will you incorporate user ideas into solution design? Will you need their help in the testing phase? How else can you keep users engaged before the final cutover? Have you segmented the stakeholder population, looking for evangelists or early-adopters to provide the right buzz? As project manager, you may not have time to do all of this, but identify a role on your project team to take on these actions. They'll pay off. ...

... "ensuring that the right stakeholders have been identified, particularly in an IT project – the user community, and that there's a mechanism for them to be involved in the project design and monitoring the progress of the project as it proceeds. " ...

Via Canada ITWorld: Stakeholder collaboration

Change Management Situational

Get aligned, find a champion, and leverage the art of change management to your project situation. ...

... "In my experience, successful projects tend to revolve around a certain type of project manager or coordinator. Someone who really knows the organization, is respected, collects chits constantly, listens well, doesn't personalize disagreement, remains flexible, and generally wraps a friendly persona around a persistent pursuit of project objectives. " ...

Via CMS Watch: Change Management Challenges

HR and IT Collaborate For Successful Change Management

HR and IT have areas of synergy that contribute to successful projects. The workforce and key talent have a special role in embracing organizational change. ...

... "If successful, the plan will produce a community of people who understand the reasons behind the change, the impact on their roles, and their role in the success of the transition. " ...

Via SMBedge: HR and IT Collaborative Success

Project Failure Brings Great Lessons

Andrew Makar has an excellent article on Projects@Work outlining key lessons from a prior project failure. I even like his tag line stating that he is "focused on effectively translating project management theory into actual practice." Indeed, that's where the real lessons are to be found.

It looks like it's part of a series---at least a two-parter. This one has lessons about defining clear roles up front, keeping the same project manager throughout the project, maintaining a "living schedule," prioritizing elements in project scope shoulud tradeoffs be needed, and establishing a clear change control process.

I couldn't agree more. Read on...

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

Project Sabotage

If you wanted to sabotage a project even if leadership showed support for it, what would you do? Leadership support is necessary, but not sufficient. Look out for these signals. Have a strong change plan than purely compliance-driven, unless absolutely necessary. ...

... "Confuse meetings with plausible, but pointed, questions. Be too busy to do what's expected of you, e.g., fail to supply data or other resources. Or send a subordinate in your stead " ...

Management Support: Panacea?

IT Project EQ Change Project

For an IT project to have impact, it must affect change. For change to stick, leaders must provide support. Recent study looks at IT projects and the distance of senior leaders, such as CEOs. ...

... "We have to get good at how our organisation handles change - that's nothing to do with IT, but no IT project worth its salt doesn't affect change, said Green. " ...

Via ITPro: CEO IT Imperative

ITIL and Project Management: A Primer

For anyone managing IT projects, you may have come across ITIL (Information Technology Infrastructure Library). If not, you will. It's fast becoming the de facto standard for IT services. This article from CIO Magazine offers a good primer on ITIL.

Many organizations mistakenly look at project management and ITIL as two distinct paths. Forward-thinking companies integrate the two, with project management methodologies blending seamlessly with ITIL's best practices in change management, release management, configuration management, and other processes.

Here's the article...

The ABCs of the IT Infrastructure Library (ITIL) - ITIL - CIO

Management Truths: Can You Handle It?

Jack says you can't handle the truth. But if you're ready, I highly recommend Stephen Robbins' excellent book, The Truth About Managing People... And Nothing But the Truth.

Robbins has sold over 2 million copies, and I can see why. In plain, simple language, Robbins outlines 63 truths, supported by evidence, stories, and examples. Each truth is only a few pages, so you can open the book up at almost any page and find a gem. The whole book is under 200 pages in a small paperpack format.

The 63 common-sense truths span the areas of hiring, motivation, leadership, communication, team building, conflict management, job design, performance evaluation, coping with change, and managing behavior.

A few good lessons (paraphrased):

1) Productivity usually breeds satisfaction, rather than the other way around.

2) When interviewing, don't go on traits. Instead probe about past behaviors (i.e. "Tell me about a time when you ....")

3) Put people in jobs that match their personalities.

4) Out of all the traits people have, conscientiousness is the most frequent predictor of success.

5) Specific stretch goals produce higher output than generalized goals like "do your best."

6) Not everyone wants to participate in setting their goals. It depends on their nature, ability, time available, and other factors.

7) Judge behaviors, not people.

8) There's something to be said for "looking the part of the leader."

9) Expect the best and people will deliver. Expect the worst, and people won't dissapoint.

10) Experience isn't always a good indicator of success.

11) There's no ideal leadership style. Directive or supportive styles can work in different situations.

12) Teams often create negative synergy. Beware of loafers. Be sure to identify and measure individual efforts as well as team efforts.

13) Honor the work-life balance. Give flexibility and options.

14) Beware of the quick fix. What works for one company or problem doesn't always work for another.

For many more, and further explanations and examples, read the book!

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.

Influencing People: The Project Manager's Secret Weapon

I recently attended a presentation on self-awareness and influence by Dr. Charles Dwyer, Academic Director of the Aresty Institute’s Leading and Managing People program in the Wharton School. I was so impressed with the presentation that I bought his book, The Shifting Sources of Power and Influence.

This book was a real eye-opener, and a jewel for anyone in project management. In the book, Dwyer states three major challenges we all face:

• Dissonant Value Systems (i.e. people’s conflicting value systems, made even more visible by the advent of the media, internet, etc.)
• Diffused Power (i.e. power being spread around in a matrix fashion, with more and more decentralization and special interest groups, etc.)
• Limited Resources (We all face a limited set of resources, made even more challenging by our lack of a mindset geared towards accepting tradeoffs, or a good mechanism to guide operational priorities)

Sound like any projects you know?

Dwyer goes on to caution that public statements, such as vision, mission, organizational values, etc. may be useful for articulating the values of the leadership or giving people a sense of structure, but do not in themselves change anyone’s value systems. Many leaders assume they can use these statements to change people’s value systems to match organizational values, but this is a myth.

What is needed instead is the ability to influence others by getting them to change their behavior to match your values. To do this, have a clear picture of what you want the unit to look like; set specific, measurable objectives; and insure that people have a way of achieving those objectives.

According to Dwyer, some tried and true methods include asking people for help, offering or implying something in return, or influencing indirectly (i.e. working through someone else who’s in a better position to influence).

Dwyer points out five guidelines for influencing people (I’ve paraphrased them):

1. Insure they have adequate capability (Do they know what to do, have the competence and self-confidence to carry it out?)
2. Address their perception of “Potential Value Satisfaction” (WIIFM or “what’s in it for me”)
3. Address their perception of the probability of value satisfaction (i.e. Do they trust you? You must build trust through visible examples.)
4. Address their perception of cost (Do this by giving them alternatives or a sense of options, and helping them understand the costs and implications.)
5. Address their perception of risk (Try to assume or distribute some of the risk. Don’t ignore it.)

These are the five things everyone weighs in their mind when someone attempts to influence them. In essence, the five elements (four of which are perceptions) make up an equation for behavior. We can influence people’s behavior by addressing this equation (I’ve paraphrased for simplicity):

Behavior=Capability + (Perceived Value * Trust factor) – (Perceived cost and risk)

These are just some of the gems of wisdom in Dwyer's book. He offers reams of memorable examples, often with a humorous style. With 90% of a project manager's job being communication (including influence), I highly recommend Dwyer’s book for project managers, or anyone in a leadership position for that matter.

Critical Chain Insights

There's a good article on Projects@Work about Critical Chain Project Management, with some insights from the field.

Still, organizations are slow to adopt it. The biggest roadblock is getting management to change their mindset, especially when it regards avoidance of multi-tasking and not focusing on task completion dates.

It's not foolproof, and makes some generic assumptions (i.e. assuming everyone pads their estimates), but certainly there are some valid points of CCPM that should be considered. Even if an organization doesn't buy into all its philosophies, they shouldn't throw the baby out with the bathwater.

Here's the article...

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

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

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

Quality vs. Quantity: Is it Really a Choice?

There's an article in CIO magazine about how business leaders are beginning to choose quality over quantity (although the evidence seems to be to the contrary). The article refers to quantity as faster, more, cheaper, etc. But is it really a choice?

With adequate up-front research, phased deliverables, frequent communication, and good change management practices, we can achieve both. Phased deliverables provide earlier benefits (i.e. speed), fact-based learnings, less resistance, less rework (i.e. cheaper) and many other benefits. Change management practices insure that the rollout of any new feature or product won't break something (the level of change management needed must of course be appropriate to the type of product and industry).

And so what if it turns out through the early phases that requirements must change or more features are needed? As long as the change impact is managed and the change is agreed-upon, that's perfectly fine. These value-based course-corrections are another advantage of phased deliverables.

These precautions are the difference between speed and haste. As Patton said, "Haste is speed without planning." Indeed, we can achieve quantity and quality.

Here's the CIO article...

Getting Quality Over Quantity Better the First Time Around - Business Pulse - Leadership RC - CIO

Process Change Management: The Challenge ...

Chris Koch shares insights on the challenge associated with changing processes, such as a data center's adoption of ITIL practices. The carrot and stick approach is outdated. The new science of change must create the spark that engages the workforce in the change by making their jobs more interesting, creating an appealing environment, and strengthening team relationships. ...

... "The change is part of a larger effort to implement the IT Infrastructure Library (ITIL) process framework to improve overall productivity. " ...

Via CIO: The New Science of Change ...

Change Management Project: HP Values Transplant ...

HP values in need of transplantation. Anyone up for that change management project? ...

... "HP needs a values transplant. Hard as it is to believe, the company that once was the epitome of wise management in the IT business has become a corrupt, dysfunctional travesty of itself. " ...

Via Computerworld: HP: No Surprise

Einstein Project Management Tip #7: Focus on Strengths

Marcus Buckingham said it in all three of his books. Peter Drucker said it. Warren Bennis said it. Dennis Littky said it. And Albert Einstein said it.

Specifically, Einstein said:

"Once we accept our limits, we go beyond them."

I think all the great thinkers agree that it's better to focus on strengths (yours and the individuals on your team) than it is to endure the futility of trying to correct weaknesses.

If we accept our limits and those of the people on our team (after all, as Marcus Buckingham points out, people's nature doesn't change all that much), then paradoxically we can rise beyond those limits.

If so many experts agree, then why do organizations persist in trying to develop people's weak areas to make "perfectly rounded people" instead of building on their strengths? If we instead worked around people's weaknesses, either with complementary partners, more fitting assignments, or support systems, we'd see much more productivity. Perhaps Peter Drucker said it best: "Make weaknesses irrelevant."

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

PMOs and Resource Management: A New Role?

There's another interesting article at Projects@Work on PMO design.

This one, written by Terry Doerscher of Planview, endorses taking what I'd call a "whole systems" approach to PMO design---i.e. looking at the PMO in the context of the overall "technology services organization."

This means expanding beyond just the project management realm---in particular, facilitating the planning and prioritization of activities across projects and other work that compete for the same resources. In effect, the PMO becomes a facilitator for managing the supply and demand of all IT work.

I'd add that, while this is a worthy role for the PMO, there is some heavy change leadership that needs to happen in order to make this successful. All too often, organizations overlook this and throw the fledgling PMO to the wolves.

As for project management practices, Doerscher suggests taking a more realistic, iterative approach to planning---something I couldn't agree more with.

Here's the article, well worth a read...

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

Einstein Project Management Tip #2: Think Flexible

In keeping with our Einstein theme, here's our next project management tip from the great thinker himself.

"As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality."

While Albert Einstein was referring to the laws of mathematics, surely this applies equally to project plans. We lay out in fine detail what we think is the ultimate plan that supposedly reflects reality. We make what we think are valid assumptions. Then, the minute it is published, things change. Life has a habit of doing that, despite our best intentions.

But we still need to go through the act of planning if we are to think through the risks and have a good chance at success.

Therein lies the paradox. We need to plan, and then we need to constantly revise the plan to match reality. Then we need to plan again. It's a continuous iterative process of course-correction. Perhaps it's why Eisenhower said, "Plans are nothing. Planning is everything."

For most projects, the old adage,"Plan the work and work the plan" should be taken in a different context than its original intention. We need to plan the work, and then we need to "work the plan" (meaning "continuously adjust the plan so that it remains adaptable") , as opposed to merely working "to" the plan.

Stay tuned for more Einstein project management tips.

ITIL CMDB: Survey Insights ...

Evergreen shares insights on aligning data center projects with creation of a configuration management (CMDB) database, which is a core component of ITIL. Current state information is needed to jump-start the CMDB, but the data must be maintained through change management to sustain its value to the enterprise. ...

... "As companies are gathering this data, Evergreen suggests that they adopt a CMDB approach to 1) aid in the execution of the data center initiative itself and 2) ensure that this critical data is kept current and made available to the rest of the organization. Key benefits of capturing and maintaining this data in a CMDB include better capacity and resource planning, reducing risk associated with failed change (and a lack of configuration knowledge), and better IT operations in general due to more current, accurate, and useful data. As a core component of the IT Infrastructure Library (ITIL), a CMDB contains relevant information about IT Configuration Items (CI’s) as well as their dependencies on and relationships with each other. A CMDB can include data specific to IT hardware, software, applications, documentation, personnel, and business domains. " ...

Via Evergreen Sys: Evergreen Systems Suggests Organizations Utilize Data Center Initiatives to Drive CMDB Adoption ...

Talent and Project Management

I received the latest PM Network magazine from PMI the other day, and several things jumped out at me, especially following my last blog post on the winds of project management changing.

First, Neal Whitten had a great article about how a project analyst (what I've often called a "project control specialist") can be a valuable aid to a project manager by taking on the responsibilities of: project tools management, plan development, sub-plan collection, project support, supporting project tracking meetings, filling in for the project manager at times, and other areas that can free a project manager up to actually lead the project.

It got me thinking about the talents needed for the project manager role, the project analyst/specialist role, and any other roles needed on the project. But more than that, it got me thinking about talent management in general, and what it means to the project management industry.

Just look at these headlines, all from this month's issue:

• Attracting--and Keeping--top talent
• Executive Identity: Project managers should learn to think like executives
• A People Person: Succeeding in project management---and getting what you need from thise around you---requires a well-honed set of people skills
• Virtual Reality: Dispersed project teams are sparking shifts in management and leadership styles

Clearly, the talents needed to manage projects go way beyond schedule, budget, and cost control. Notice I said "talents" as opposed to skills or knowledge. As Marcus Buckingham points out in his excellent book, First Break All the Rules, there is a huge difference between skills, knowledge, and talent. The first two can be taught. The last one--talent--is innate, and cannot be taught.

This becomes clear when you apply Buckingham's definition of talent as "ANY recurring patterns of behavior that can be productively applied." Everyone has talent. It's just a matter of discovering it and matching them to the right role. The key point is that a person's nature cannot change that much, so it's important to select someone with the right talents (i.e. innate traits). Once that's done, you need to set clear expectations, motivate the person (through praise and recognition of their strengths), and ultimately develop the person (building on the strengths that already exist instead of fruitlessly trying to fix weaknesses).

So what does this mean to the project management field? Everything. It means we need to begin thinking about these innate talents when we hire and assign project managers, when we staff the project, and when we consider how to motivate the team. The talents needed for each role will be different. And, based on the nature of the project and the stakeholders involved, the talent required to manage each project may be different. There is no "one size fits all" when it comes to talent selection.

It's not that skills and knowledge aren't important, but these two items without the correct talents will not bring about success.

What I like about Buckingham's book is that it's based on facts---years of research with the Gallup organization. Anyone who selects and manages people should read this book. And when you do, think about the diverse talents needed for each person on your team, and for the project manager role for each individual project.

Project Management Winds Are Changing

There's an excellent article by Betsy Morris in the current issue of Fortune Magazine about how the Jack Welch way of winning is---dare we say---a thing of the past.

How is this relevant to the project management field? Well, for one, it means recognizing the winds of change in the industry, and how projects are selected, promoted, and managed. Above all, this impacts program and portfolio management. Particularly, note four trends in management thinking:

Innovation:

Let's take Welch's old rule of being number 1 or 2 in your market (or else fixing, selling, or closing the business). The new rule is to find a niche and create something new. The article uses CocaCola as an example of a company that was basking in their glory as number 1, but eventually realized (although it took a while) that energy drinks and bottled water were about to pass them. As the article points out, energy drinks "are now expected to outearn every other category of soft drink within three years." Parhaps marketing guru Harry Beckwith said it best in Selling the Invisible when he said that it's fine to do something 10% better until someone else comes along and does it 110% different.

Customer-Centric Management:

Welch started a whole movement of focus on the shareholder, which led many organizations to ignore the future amid pressure to appease shareholders and "make the numbers." Now, organizations realize that the customer is king. The article references several companies that have made this realization, and the trend is heading in that direction. After all, statistics show that even a minor improvement in customer retention leads to a major increase in profitability. The days of short-term thinking may be finally coming to an end.

Reinvention vs. Incremental Change:

Since it seemed Jack Welch could do no wrong, everyone imitated whatever Jack did---and Six Sigma was no exception. The problem is that, according to the article, of the 58 large companies that announced Six Sigma programs, 91% have trailed the S&P 500 since. As the article points out, that's mostly because Six Sigma is intended to "fix an existing process," whereas innovative companies that developed new and unique products (or reinvented their business) took the lead.

Stop Ranking Your Players; Inspire Passion:

Once of Welch's most controversial systems was to constantly rank his employees and regularly weed out the "C" players. But companies have had difficulty getting productivity and innovation out of "increasingly disenfranchised employees." In the article, Christopher Bartlett of Harvard Business School put it best:

"People don't come to work to be No. 1 or No. 2 or to get a 20% net return on assets. They want a sense of purpose. They come to work to get meaning from their lives."

Side editorial: For the "enlightened" approach of finding the hidden strength in everyone (something Peter Drucker always suggested), read Marcus Buckingham's Now Discover Your Strengths (or any of his books for that matter). Or read Dennis Littky's The Big Picture: Education is Everyone's Business. I assure you, you'll never be the same.

Meanwhile, I highly recommend the article (the link is below) for those looking for the latest trends in management thinking, and who want to remain one step ahead.

From a project management perspective, the handwriting is clearly on the wall. The traditional "execute to a set of deliverables" approach won't cut it. Today's project manager needs to be thinking about things like innovation, customer focus, business transformation, business acumen, change leadership, and team passion. Those focused on merely schedule, budget, and scope will soon be dinosaurs.

Fortune: The new rules - Jul. 11, 2006

Data Center Change Automation: ITIL Support ...

ITIL support for data center management by BMC integrates change with availability and capacity. ...

... "BMC is the only vendor that delivers complete ITIL-integrated workflows for changes associated with server resource provisioning, allowing data centers to link their availability and capacity management processes with change management for more controlled, effective, and efficient use of data center resources. In addition, BMC's Data Center Optimization solutions deliver a comprehensive set of ITIL-based extensions for virtualization management and optimization. " ...

Via BMC Software: BMC Software Racks Up Another Industry First: Full Automation of Data Center Change Management ...

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

Elusive IT Project Value: Book Tells How To Achieve It

I've just finished reading an excellent book on achieving value from IT projects, The Information Paradox: Realizing the Business Benefits of Information Technology, by John Thorp and the Fujitsu Consulting's Center for Strategic Leadership.

Thorp and company claim that today's IT projects are evolving more and more from simple automation efforts to complex "information" initiatives, and even further---to complete business transformation initiatives. This calls for a different approach and requires IT and Business collaboration.

As the book points out, the classic "let's buy a product and assume it comes with automatic benefits" approach doesn't work in today's more complex arena (and in fact it probably never did). In a complex business transformation initiative, trying to assume that an IT project in isolation will deliver value is wishful thinking.

The book also points out the four critical dimensions of complexity, which it says are blind spots in traditional thinking:

1) Linkage - to other related initiatives and to business strategy
2) Reach - those areas of organizational structure or supply chain processes that may be impacted by the change, or that need revisiting in order to bring about the benefits
3) People- those affected by the change and/or that need to be engaged (i.e. proactive change leadership and stakeholder analysis)
4) Time - the time it takes to manage the overall initiative, including the above dimensions, to fully realize the benefits (most companies grossly underestimate this)

Unfortunately, many IT projects just focus on on-time and on-budget delivery (resulting in a situation that the book describes as, "the operation was successful but the patient died"). Thorp and company refer to this as "investment myopia."

Instead, a committment to business value, ongoing process improvements, frequent iterations of delivery, and better project selection techniques are key. Most of all, we need to be aware of the blind spots mentioned above.

The book goes on to describe how a system of program management, portfolio management, and governance, with a focus on benefits realization, can bring about results. It also cautions about the dangers of treating selections as a one-time annual event, making selections in isolation (instead of in the context of investment programs), and not looking at all aspects of value (i.e. going beyond simple financial measures).

I highly recommend the book for those struggling with determining the value of IT, or trying to bring about collaborative change in their organizations. If you look at any major successful transformation, it was brought about by a marriage of technology, business process, and organizational change, and with full backing from senior management. This book can go a long way toward helping make this happen.

Change Management: Aim for the Heart

Christopher Koch runs a great blog on CIO.com. His latest post explores the challenges of change management, and recommends generating ways for people to get that "aha moment" for themselves. This "makes it stick" as opposed to being told that they have to change, or being shown metrics or even logical cases.

I couldn't agree more. He also offers some good examples, such as the open book approach, where people will see the numbers and hopefully deduce the need for change. A method I recommend (and which I discuss in my response to this week's puzzler on the AllPM forum), is to use stories or examples that can serve to generate an emotion such as a deep-seated need or fear. This, too, can lead to that "aha moment."

Here's Koch's full post on CIO.com...

CIO Blogs - The Primordial Factors in Change Management

Project Measurement Framework ...

Article explores the transformation experience of AGEdwards where the project management success rate was improved, through leadership training, a measurement framework, and enhanced organizational models. ...

... "Ed Pilewski, now VP of IT productivity and quality, chose not to take the traditional route of forcing a rigid project management methodology on the technology staff - a tactic that can backfire and create resistance to change. Instead, he implemented a standard framework for measuring, monitoring and reporting on a project's progress that fosters transparency and accountability. " ...

Project Measurement Framework: Via CIO: When Failure Is not an Option

Change Management: IT Leads Insurgency ...

Robert Reich challenges IT leaders to embrace change and lead the insurgency brought about from the mega-trends confronting us. He highlights the importance of adding value and ignoring past models for success. ...

... "Organizations that will thrive in the global economy will be driven not by the short-term expectations of Wall Street, Reich suggested, but by his so-called change insurgents. These educator-executives can persuade managers to develop strategies that comprehend the structural economic change brought about by globalization, technology and the graying of the baby boomers. " ...

Via Search Oracle: Robert Reich tells CIOs: Rise up and adapt to global change ...

ITIL Service Desk Software: Market Consolidation ...

Mercury acquires ITIL service desk software vendor to improve the depth of its offering. Rapid integration of this acquisition should position Mercury as a viable competitor in the service desk space with its suite approach to IT service and portfolio management. ...

... "The acquired offering is an advanced set of ITIL-based technologies that help enable companies to take a business-centric approach to managing an enterprise service desk with low total cost of ownership. This technology provides advanced out-of-the-box ITIL-based capabilities in incident management, problem resolution, configuration management, change management and release management, along with robust functionality in asset and inventory management. Mercury provides this technology as part of its Mercury Service Desk product, which is available as a strategic part of the Mercury BTO Enterprise and part of the Mercury Application Change Lifecycle solution. Mercury plans to further incorporate this technology to expand its set of ITSM offerings within the Mercury BTO Enterprise. " ...

ITIL Service Desk Software: Market Consolidation: Via Mercury Interactive: Mercury Accelerates BTO Strategy For IT Service Management With Strategic Acquisitions ...

Learn How to Manage Change

The HP Change Artists Web series, produced by HP and broadcast by CIO Magazine and CNN, is a great way to learn from the best how to manage change.

The series premieres tomorrow, May 9th, at 11:00am EDT, with Fedex CEO Fred Smith and CIO Rob Carter sharing their best practices in change leadership.

If you're managing a project that introduces fundamental organizational change, you can't afford to miss this series. Here's the URL to register...

Change Artists: A CEO / CIO Conversation with FedEx. Live on May 9

Project Planning Not All It's Cracked Up to Be

OK, everyone relax, I haven't lost my mind. Of course planning is important. But, as I've been saying for years, circumstances change the minute a plan is put on paper and a good project manager needs to expect uncertainty and know how to deal with it when it arises.

There's a great article in Projects@Work by Roger Bly that supports this approach. Bly talks about how project managers must manage the entire end-to-end process, and recommends taking a collaborative approach, using tools that enable frequent two-way communication and the ability for resources to keep the plan current and reflective of reality (something I completely agree with).

Here's an excerpt...

"A collaborative project execution application can make this process a reality in organizations of all sizes by allowing project teams to successfully tackle multiple concurrent projects. Projects are no longer constrained by static plans produced and updated only by project managers.

A project execution approach also frees project leaders from the mundane work of updating project plans, collecting progress information and reformatting information into status reports. Project plans can be collaboratively built and updated by the project team, often by reusing collateral, deliverables and templates from previous projects."

Far too often, a project manager will create an elaborate plan, and struggle to keep it current, ignoring the real issues that occur during project execution. If the team is trained to contribute frequent updates of remaining time (and any changes to the plan), the project manager can spend more time leading and monitoring as opposed to administrivia.

Of course, another easy way to accomplish this is to update the plan and percent complete collaboratively at a weekly meeting on an overhead projector, but it's ideal if the resources can update their own activities electronically.

For more about the need to focus on execution and communication, read the full article...

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

Project On-Time, On-Budget: The Truth Is Out There ...

IT Week reports on insourcing of CRM project by Centrica, that was experiencing delays in its final phases when implementing SAP billing capabilities. This situation would be challenging for any implementation partner. Its a perfect storm: Siebel CRM, SAP Billing, legacy systems, third-party implementation, systems integration, and organizational change management. It may not be late, but really on-time, if the magnitude of effort was estimated correctly. ...

... "Energy giant Centrica has moved its GBP400m transformation programme in-house, taking back the running of the project from consultancy Accenture. " ...

Centrica takes back IT project: Via IT Week

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.

Business Process Redesign Projects; What to Look Out For

Here's a great article from the IEEE Engineering Management Review on Business Process Redesign (BPR), by Yogesh Malhotra.

The article offers an excellent overview of BPR and explains why 70% of BPR projects fail and what to do about it.

According to the article, the main barriers are:

(i) Lack of sustained management commitment and leadership;
(ii) Unrealistic scope and expectations;
(iii) Resistance to Change.

The article emphasizes the importance of building a shared vision, having sufficient budget and resources, avoiding a cost-cutting focus in favor of a strategic vision, involving IS and HR, and most importantly, piloting on a smaller scale first (or what I like to call, "Think bold, implement safely")

Here's the article...

Business Process Redesign: An Overview (Article)

Earned Value Management Trends, Best Practices, and Pitfalls

A few weeks ago, I commented on Part 1 of a three-part series on Earned Value Management on Projects@Work.

While Part 1 set the stage and illustrated some of the challenges of EVM, Part 2 of this excellent series offers some excellent case studies and learnings.

For instance, the US government agency, OPM (Office of Personnel Management) cites the following critical success factors:

- Continuous executive sponsorship (not just up front)
- Committment to funding for adequate tools and training
- Adequate allocation of project managers' time to manage using this system
- Piloting EVM in a small group of projects to illustrate success and fine tune the details
- Not underestimating the culture change management required, involving employees, managers, and timekeepers. Regularly maintained training and job aids are critical.

Another organization, Inter-Coastal Electronics, cites having shallow, simple WBS templates in their ERP system as a key success factor. They claim that a WBS that's too granular becomes too difficult to manage. I couldn't agree more.

I highly recommend this series to anyone attempting to introduce Earned Value Management in their organizations.

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

ITIL Best Practice Projects Accelerating ...

Voyence's survey results on ITIL adoption shows that approximately half of those surveyed expect to accelerate ITIL best practice projects over the next 18 months. Change and configuration management were selected as the most important ITIL implementation. The next most important ITIL-candidate processes were incident and problem management. ...

... "Voyence, a pioneer in automated change and configuration management solutions, announced the results of a survey taken at Pink Elephant's 10th Annual International IT Service Management Conference from Feb. 12-14, 2006. Voyence sampled 83 random IT administrators at the show to determine the industry's readiness for regulatory compliance demands and how quickly the industry is adopting IT Infrastructure Library (ITIL) best practices. " ...

ITIL Best Practice Projects Accelerating: Via Voyence: Survey Reveals More Than 90 Percent of IT Managers Cannot Prove Network Compliance With Government Regulations: Survey Indicates ITIL Best Practice Projects Accelerating Due To Compliance Requirements ...

ITIL Implementation Webcast Advice ...

Recent webcast by Managed Objects validates the hype associated with ITIL implementation. Some good advice was shared: Adopt ITIL in small pieces with a focus on top business services and their key performance indicators. Avoid the proliferation of tools to support ITIL adoption. Some not-so-good advice was evident: Select tools first and then automate processes.

I would recommend focusing on the process first, redesign as necessary, train and support people in their roles, and then implement tools in stages consistent with your desired change in process maturity. ...

... "Over 500 registrants for the webcast validated that the ITIL adoption topic is top-of-mind for many enterprises today. In fact, according to Forrester Research, with in the past year ITIL adoption of $1B+ revenue companies has increased from 13% to 20% , with that number projected to grow to 60-70% by 2008. " ...

ITIL Implementation Webcast Advice: Via Managed Objects: Business Service Management Required for Successful ITIL Adoption: Independent Research Firm tightly links BSM and ITIL Best Practices during recent Webcast ...

Fighting the Status Quo; A Lesson from an Education Reformer

Reading Dennis Littky's The Big Picture: Education is Everyone's Business has been very inspiring. Just as Littky challenges the status quo in the education system, we must do so in our organizations.

Here's a quote I especially like in the book:

"No matter how far you have gone on a wrong road, turn back"
- Turkish Proverb

I've listed 21 key points, paraphrased from the book, to illustrate how the same issues that face the education system apply to creating a learning environment in business...

1. Teach how to think flexibly, not that there's a right way and a wrong way for doing everything. It's worth noting that the best tennis players hold the racket the wrong way.
2. Create an environment that allows students the freedom to find themselves with the support and motivation of inspiring adults [leaders]
3. Teach students to fish; don't give them fish. Quote: "We have plenty of people who can teach what they know, but very few who can teach their own capacity to learn" - Joseph Hart
4. Use collaborative learning - i.e. "What do we think of this passage as compared to this one?" etc.
5. Teaching and learning are about problem solving. Put teachers and learners in the best possible environment for them to do this together.
6. Don't dismiss someone as "dumb in math" or "uninterested in science." Cater to their strengths [as Peter Drucker says, "Make weaknesses irrelevant" and pair people with complementary strengths if need be]
7. Don't measure education [or any kind of success] by the number of minutes a kid sits at a desk.
8. Remember the Three R's: Relationships (with teachers, community, parents, etc.), Relevance (to the students lives and passions - i.e. "what's in it for me"), Rigor (allow them to concentrate intensely in an area of their interest - build depth, not breadth)
9. Insure a shared philosophy among the principal and teachers [i.e. management]
10. Fix the atmosphere. Create an environment for learning. Fun, happiness, respect, kindness.
11. Build celebration into the culture. Celebrate often, for various occasions.
12. Know who really sets the culture of a school [or organization]. It's the senior students [middle management and vocal champions -- what Seth Godin calls "the sneezers" --those who can spread an "idea virus"]. Engage them in recreating the culture, and others will follow suit. You can't change the culture by holding a special assembly [or a meeting or a memo]
13. Never make rules based on the exception.
14. To build trust and respect, provide responsibility and decision-making to students, and control over their environment, tools, and learning
15. A culture can thrive and grow on its own stories. Every interaction helps build the culture.
16. Start with the student, not the subjects or classes. Quote: "One size never fits all. One size fits one." - Tom Peters
17. Use real world examples - or better yet, real projects. Students can tell when things really matter and when they're contrived. [so can business people learning project management]
18. Don't give grades. The real world is based on giving feedback and showing people what they need to do to improve. It helps students succeed. Grades are meaningless, subjective, and can destroy morale. Use a narrative instead. It's a tool to help learning, not evaluation for evaluation's sake.
19. Quote: "Nobody grew taller by being measured." - Phillip Gammage
20. Measure what counts. There is no one indicator of success that fits every student. Instead, measure how often a student talks to teachers about their problems [builds the right culture]; measure if parents agree the school is a safe place and that it views parents as partners [i.e. customer satisfaction]
21. Friends of change [6 C's] are: concentration (on your philosophy), commitment, conversation, collaboration, caring, conviviality

Mining for Talent; Fielding a Good Project Team

Tom Peters has been blogging about a book by Dennis Littky called The Big Picture: Education is Everyone's Business. Now I can see why. I purchased the book and it's revolutionary. Littky is a pioneer in the education industry and has achieved startling results with his focus on students as individuals. But the book isn't just for those in education, it's for anyone in a leadership role.

Much like the theme of How Full is Your Bucket, the subject of my previous post, it focuses on finding the hidden talents in the individual, and not just basing decisions on grades, scores, or averages. I'm still reading it, so I'm sure I'll be posting more on it in the near future, but so far it's a very enlightening book, and makes so much sense it's scary.

I've always subscribed to this philosophy, as I feel that fielding a good team in business is no different than fielding a good team in sports. You need to find people's desires and areas of talent (nearly everyone has some), encourage them to build on that talent, and put them in the right positions to exercise that talent. Combined with positive reinforcement (which elevates their self-confidence), they will shine as individuals, and if well-matched with others (team dynamics), the team will shine as well.

I recently saw yet another source that supports this theme of "mining for talents." I just subscribed to Leadership Excellence magazine (and in fact have been asked to submit an article to them, which will most likely appear in their April issue). On their website, I saw this quote from leadership guru Warren Bennis...

“It became clear to me that to understand Drucker’s philosophy of management, you need to know his philosophy of education. In fact, they are one and the same: Honor individual differences. Take people as they are. Don’t attempt to change or manipulate them to be like or to become somebody else. There is no one right way. Organizations are as much learning environments as they are socially useful institutions established to produce goods. At their best, they make available sufficient roles where individual strengths can contribute to productivity and where individual weaknesses are irrelevant. There is virtually no such thing as an ineffective worker, only a worker whose areas of competence are inappropriate for a particular role.”

—Warren Bennis, consultant,
Leadership Excellence, January 2006

Very inspiring words.

Innovation in Project Management; A Lesson from Ford

Tom Peters blogged recently about Ford, Pixar and the new wave of innovation sweeping companies. Although he had a softer spot for what Pixar is doing, the main point was that innovation is the new world order. Operational excellence is out, as is short-term thinking and reactionary cost-cutting. Even GE is now all about innovation.

Just look at these enlightening statements in a recent announcement from Ford CEO, Bill Ford, announcing their renewed focus on innnovation...

Ford Motor Company stands for a far-sighted commitment to growth. We stand for a renewed focus on the customer. We stand for boundless innovation in every aspect of our business...

Here is what we will not stand for: incremental change, avoiding risk, thinking short-term, blocking innovation, tying our people's hands, defending procedures that don't make sense, and selling what we have instead of what the customer wants. In short, we will not stand for business as usual.

Going forward, our employee evaluations will include a section on innovation. We’re also going to design compensation plans that reward new thinking. And we’re going to create a way for employees to appeal a decision, even if they have an idea and the boss says no.

These are inspiring words. Don't be surprised to see this approach make its way into the project management field. Instead of taking a project charter and "executing well," enlightened project managers will encourage opportunity assessments, get their teams and management excited about new ideas and concepts (assuming they're not squashed), and attempt to try new methods.

We've been posting recently about Agile Scrum Project Management. That's just one example of something that's new and different, but will most likely not gain ground in traditional, conservative organizations.

Here's more from Bill Ford's presentation...

Innovation Acceleration: Innovation-Driven Vision: Ford Motor Company

Agile Scrum Project Management; Applicable to All Projects?

I just finished reading Agile Project Management with Scrum, by Ken Schwaber, and the case is most compelling.

As we've posted here, Scrum is all about daily communication and short 30-day iterations focused on business value. No doubt it's a change from traditional project management, but it takes a sensible, pragmatic approach. As the author points out, Scrum is about "the art of the possible" and especially shines when dealing with complex initiatives (which most IT projects are).

While the book is geared toward software development projects, I found myself asking if this approach would apply to other projects, such as implementing packaged software, or even non-IT projects. I think the answer is a definite "yes." However, the first round may take longer than 30 days, depending on the complexity of the configuration and a hundred other variables.

Suffice it to say that time-boxed iterations focused on delivering some level of pre-defined business value at each iteration is the right way to go for most projects, and certainly most IT projects. Phased deliverables offer earlier payback, quick wins, and allow the flexibility of changing course in future iterations. That sounds like a win-win to me!

Microsoft Poised to Take the IT EPM Market

It's like the tortoise and the hare. For years, Microsoft has been evolving its low-cost MS/Project suite and capturing the IT market, while mega-EPM providers such as Mercury, Niku, and Planview focused on meeting enterprise portfolio needs.

Now things are about to change. As we reported a few weeks ago, Microsoft acquired UMT, a leading EPM consulting firm. This brought technology and expertise to enable Microsoft to release a truly enterprise-driven product. Since Microsoft still owns the IT market by a wide margin, this will no doubt steer IT organizations in this direction. Whether other industries follow suit remains to be seen.

Microsoft has code-named their new product Microsoft Office Project "12". It is expected to be delivered in the second half of 2006, so design work has been well underway.

For more details about what Project "12" will offer, see PMForum's news update...

PMFORUM, Connecting the World of Project Management PMFORUM Breaking News: MICROSOFT ANNOUNCES NEW INNOVATIONS IN ENTERPRISE PROJECT MANAGEMENT

Agile Project Management with Scrum

I have been wondering lately, what does agile really mean here?
This article says, Agile means responding to change - both technological change and changes in requirements perhaps due to customer demand and market opportunities.

It makes sense to me that this would be needed. The world is spinning much faster now and people expect content on the web, for example, to be relevant.

How does this differ from typical PM approaches? It has an answer there too...
-----
More traditional project management "command and control" approaches assume the relationship between the inputs and outputs of a software development process are stable and predictable and that the schedule of outputs will still be relevant by the time they appear. Scrum accepts the fact that things are going to change and takes an empirical approach.

In Scrum work is delivered in monthly "sprints". Each sprint delivers a single, usable piece of work called the "product increment". This product increment is immediately available for evaluation and use by the customer at the end of a sprint. Projects managed in a "command and control" style often have an infrequent release schedule. This can result in a gulf between customer expectations and reality. Scrum requires these predictable, frequent releases to ground customer expectations on demonstrated, working code rather than the false comfort of forecasts and reports. Short of an emergency, stakeholders aren't allowed to approach developers formally or informally with requests to do additional work during a sprint. This gives the development team enough stability to be able to complete a product increment without being distracted by the noise of external disruptions.
-----
Now that last part about not having stakeholders formally talk to developers is something that I try to enforce on my projects also. So, maybe it's not so different after all...to learn more visit:
ITWALES.COM - Agile Project Management with Scrum:

Project Portfolio Management: IT Business Management Solution ...

Touchpaper introduces new project portfolio management (PPM) system that drives IT business alignment. ...

... "Touchpaper has launched a new product portfolio underlining the company’s IT Business Management (ITBM) strategy and its vision for an ITBM enabled organisation where the IT and customer service departments measure themselves against the strategic and operational goals of the business. Aimed at commercial and government organisations, the Touchpaper ITBM suite is available through the company’s direct sales channels and via its international network of Value Added Reseller (VAR) partners. Many customers have already committed to the new Touchpaper ITBM solution including Hachette Livre UK Books Group, London Borough of Hillingdon, London School of Economics and Political Science, Newport City Council and Sanimed.

Specifically, Touchpaper’s ITBM suite can help deliver projects that drive business growth and value; meet customer needs and pre-defined levels of service; achieve governance and regulatory compliance; link business and IT strategies, plans and relationships; demonstrate the business value of IT; apply metrics to IT; budget and manage IT spending; foster change in business processes and manage risk. " ...

Project Portfolio Management: IT Business Management Solution: Via Touchpaper: Touchpaper Launches New Solution for IT Business Management ...

SOX 404 Solution: IT Controls Automation

New software release incorporates controls automation, testing, and reporting in a comprehensive library of business processes. ...

... "With the new release, MetricStream Design now enables users to identify any control as a process-level application control or a process-level general IT control or a process-level manual control. In addition, MetricStream Design now enables users to capture general IT controls by defining IT as a separate function with various processes such as acquisition, change management, service level monitoring, security, incident management etc and enabling customers to easily comply with COBIT, ISO17799 and ITIL standards. MetricStream Assess now provides a framework that automates the testing of process level application controls and reports the results for the entire test - including manual and application controls, in an integrated manner and also provides an out-of-the-box library containing more than 1500 tests for automating the testing of application level controls in general ledger, procure-to-pay, order-to-cash, inventory / cost Accounting, asset management and payroll processes. " ...

SOX 404 Solution: IT Controls Automation: Via MetricStream: MetricStream adds full support for IT Controls and Automation of Application Control Testing in its SOx 404 Solution ...

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...

Agile vs Big-Bang Project Delivery; Argument Solved

For years now, proponents of realistic IT approaches have been touting the importance of agile or spiral development. And aficionados of traditional "plan everything up front" approaches have been counteracting this by stating the need to agree to a fixed scope, and stay on time and on budget.

Several weeks ago I mentioned an excellent book that addresses this subject; Software Projects: Evolutionary vs. Big-Bang Delivery, by Felix Redmill. I finally finished reading it, and it points out how to resolve the differences, with a reasonable and sensible approach.

Again, the book is expensive (well over a hundred dollars), but can be found used for around fifty dollars on Amazon.com.

Below, I've paraphrased and summarized the key points:

• Be sure to understand and state the business objectives up front. This is too high level for an adequate estimate, but it's a start.
• Then conduct a feasibility study, analyzing as much detail as possible before authorizing the project. Most organizations skip this step, with bad effect. Aim for an aggressive but realistic target.
• Beware of random constraints assigned by senior management, with no strategic cause. Most projects fail because they attempt to hold to unrealistic or arbitrary constraints. If necessary, document the risks of adhering to the arbitrary deadline and review with them. Negotiation tradoffs in scope, time, or cost as needed - or break the project into multiple phases.
• It's still too soon for a definitive estimate, but the results of the feasibility study should be submitted as an "order of magnitude" estimate, along with risks and a plan for mitigating them. This becomes the business case for the project.
• Make sure senior management understands that change is inevitable as the project progresses. But this change should be still be governed and weighed against the business objectives. Reassessment gates can be used to reset expectations of when the project ends.
• Not all change should require governance. Project managers should have the leeway to use their own judgment to change tactics accordingly as long as it's within the business objectives. They should not just "follow procedures."
• It should not be expected that all work will be done within the confines of the original document. For instance (and this is my example, not from the book), if implementing a purchased software project, a feasibility study would have been done before the software was purchased, configured, and tested. Upon configuration or testing, new discoveries/issues can (and probably will) occur. The only way to truly mitigate this is to do a pilot. Aside from that, expect changes.
• This is a HUGE culture change for most organizations on the part of senior management. Without this level-setting, management will expect all work to be held to the original estimate, and judge success against it. This is the key reason why most IT projecst are seen as failures. We must manage stakeholder expectations (and that includes senior management).
• Project progress should be weighed regularly against business objectives and not the completion of tasks. These objectives and the project's ability to meet them should be reassessed at each phase gate, with escalation of any variances to management. Again, this is the time to reset when the project ends, if necessary. This is also a huge culture change for senior management in most cases.
• Scope should be revised as needed and documented at each step, so there's a record of the approvals and rationale for changes. Reasons of variations should be captured as lessons for future estimating.
• Agile or evolutionary development is not an excuse to ignore change management. But change must be expected. To hold firm to a detailed schedule up front is not realistic for most IT projects.
• Maintain close contact with users throughout the project to assure success.

This sounds like a sensible approach, but does require level-setting with management. Again, many project failures are a result of not setting the right expectations with management. Otherwise, a project can be a complete success, but management is dissapointed. This destroys morale and unfairly judges the project as a failure.

I recommend the book for those who want to learn more, as the book goes into far more details and offers examples, processes, etc. Here's the Amazon link...

http://www.amazon.com/gp/product/0471933430/102-4494239-8790520?v=glance&n=283155