Crowdsource Approach to Projects

Wave Communications in Projects

Google demonstrates its Wave communication product and you can see its powerful applicability to collaborating project teams. ...

Teams Self-Organize

Virtual is Green

Managing a project virtually? Team dispersed globally? Travelling less? Team wearing pajamas and fuzzy slippers, yet project remains on-schedule? Using collaborative tools, such as team workspaces, teleconferences, virtual whiteboards, instant messaging, web seminars, etc.? You are enabling sustainability in your enterprise. Do this across your project portfolio and there is a tangible payback. ...

... "Lotus Notes and Domino 8.5 for collaboration that offers green benefits for end users and IT departments by enabling significant reductions in travel and commuting. " ...

Via : Software for a Greener World

Under one roof

It's not a new thought. But it does drive home the point that very different industries have similar issues when it comes to project management processes. The thought is that when you have a project where the schedule is being squeezed, it's good to have your project team working as efficiently as possible.

At a client recently, the question came up - how to recover some lost time and to prepare for expected mandated scope additions? It is a traditional multi-national organisation with distributed departments. Project team organisation follows a medium to strong matrix model. The program comprises several linked projects with distributed teams and the program has very high priority within the organisation.

The response of one project team is to co-locate the team in one space to improve the team communication and efficiency. In justifying the cost of co-locating to management, examples from a drug company, a car manaufacturer and information technology were cited. These examples are interesting because they do underline the similarity of issues in organisations where you would not normally look for them.
Bringing IT under one roof

Glaxo Mimics Carmaker to Speed Vaccine

Quality is Job One

Who said that? ... What is the right balance of quality, schedule, and budget on an IT project? It's situational. Just know which one is most important and plan accordingly. ...

... "Quality happens only when careful planning is done, when the entire project team maintains a quality-conscious approach every step of the way, and when problems don't escape from the phase in which they were introduced. " ...

Via CIO: Software Quality Control

Project Influence: Check Your Ceiling

Need to focus your project team on getting work done: lower the ceiling. Need to get your team in a creative mood: raise the roof. ...

... " These researchers feel people under high ceilings are primed to think broadly because of the sense of freedom associated with the space, while the containment of a lower ceiling encourages people to think small and focused." ...

Via Good Morning Thinkers: The Roof

Don't Do This To Your Project Team Member

Project Controller: The Project Manager's Best Friend

Halleluyah! Finally, there's an article saying what I've been saying for years. With projects becoming more and more complex, and leadership and stakeholder management requiring more attention than project managers have time for, there's a need for another role to manage the "control" aspects of the project.

This article by Robert Wourms on Projects@Work details how organizations such as State Farm have had success doing just that. Bring on the Project Controller. As a member of the leadership team for PMI's new standards for program management and portfolio management, I witnessed first hand how valuable this role was, as it freed the program manager up to actually lead the program.

The article shows how the project controller's role can include tasks such as:

1) Educating the team on processes
2) Facilitating Planning and Control sessions
3) Developing the project schedule
4) Controlling progress
5) Tracking and analyzing costs
6) Managing Issues, Risks, and Changes
7) Documenting and delivering status information

So what's left for the project manager to do? Plenty. Supporting this, the article offers a valuable table outlining the role of the project manager vs. the program controller. Read on...

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

Project Team Sizing Heuristics

Nice heuristic --- rule of five for project team sizing. Its good to have a starting framework of roles for projects and modify to the situation. ...

... "When building your next project team think in terms of five and you'll be able to maximize your business and technical capability to deliver a solution on time and on budget. " ...

Via POWERBUILDER DEVELOPER'S JOURNAL: Project Team

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 Execution

Tom Peters and crew on strategy implementation through execution ... here's a chance for the project manager to shine ... Get the leadership support. Break the plan into chunks. Schedule the first chunk and resource the team. Start driving. ... Sounds simple. ...

... "Great execution happens in small manageable chunks by taking large plans and breaking them into manageable parts. Otherwise, the path to execution can seem so overwhelming, people can't conjure up the energy. " ...

Via tompeters!: Execution through Projects

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.

Project Teams: BioTeaming

Interview of Ken Thompson, architect of the BioTeaming methodology, which studies animal behaviors in order to apply these techniques to better enable human teams. ...

... "finding ways for humans to work together better, too - he calls the methodology BioTeaming. " ...

Via ScobleShow at PodTech: BioTeams Video Interview

Olympic IT Project: Risk Management Challenge

Atos project team will manage the Olympics IT project for Vancouver games. It manages risks by leveraging accumulated knowledge and experience forward. Lesson learned, knowledge transfer, sustaining core team members, and scaling high-performance teams are all ingredients of successful Olympic technology events. ...

... "In June 2006, only months after completion of the Torino 2006 Winter Games, Atos Origin dispatched IT managers and engineers to already start working on the Vancouver project. Currently the size of the Atos Origin IT team in Vancouver is around 15 but the team will grow rapidly over the next couple of years. During the 2010 Winter Games, Atos Origin will manage the technology consortium team estimated at 2,000 staff, including 400 Atos Origin experts, made up of locally hired staff, local volunteers and overseas Olympic Games technology experts.

The complex, massive IT infrastructure of the Olympic Games is deployed by large teams of people into different cities in different countries every other year. Such a major task is all about risk management capitalizing on the knowledge gained from previous Games Operations. This knowledge and experience transfer is critical in keeping costs down and in lowering the risk of future Olympic Games. " ...

Via Atos Origin: Atos Origin IT Team already in place for the Vancouver 2010 Olympic and Paralympic Winter Games

Project Management Training: Foundation For Success

With federal IT investment slated to increase, info technology professionals in government would be well-served by training in a foundation of project management basics. ...

... "officials interviewed for the study said their teams lacked or may lack sufficient training to effectively estimate costs, identify risks and develop baselines from which to plan project costs, schedules and technical requirements. " ...

Via Federal Times: Link

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

Lean IT Strategy: Virgin America

Virgin America needs a cost-effective, yet differentiated strategy, in the US market and its IT strategy must be based on a low-cost model. Its CIO plans to run an efficient data center, negotiate smart contracts, and leverage open-source platforms. ...

... "And their IT strategy will be, of course, lean and mean. " ...

Via CIO: Link ...

Company Info: A U.S. majority owned and controlled company, Virgin America intends to launch domestic U.S. scheduled airline service utilizing new Airbus A320 family aircraft beginning in 2006. The company has announced agreements to take firm deliveries of 34 A320 family aircraft including 19 purchased aircraft from Airbus and 15 leased aircraft from GE Capital Aviation Services. Virgin America's corporate headquarters is in the San Francisco Bay Area, and its principal base of operations is at the San Francisco International Airport. Virgin America's goal is to build an innovative, creative travel brand based on safe and efficient operations, low costs, outstanding guest service, and a unique level of engagement by its team. Its mission is to create an airline people love.

PMI Project of the Year: From Wasteland to Wildlife

I was recently in Seattle for a PMI leadership meeting as part of the core team for the Program and Portfolio Management Standards program. First, I was impressed by the beauty and cleanliness of the city, and the friendliness of the people. And of course I had to grab a coffee at the first Starbucks and see the guys at the famous Pike Place Fish Market throwing fish to each other. But I digress.

What really floored me was being at the PMI Awards presentation and seeing the short film on the project of the year---the Rocky Flats Closure project. This was a former nuclear weapons facility (and wasteland) that had to undergo an immense cleanup, including nuclear deactivation and material removal. Except the result wasn't a mere cleanup---the site was turned into a beautiful wildlife refuge, and will soon have a public space for hiking, biking, and horseback riding.

It demonstrates what can be achieved when you blend passionate leadership and sound project management. The project's website is below...

Welcome Rocky Flats Environmental Technology Site (Main)

Critical Chain fever chart example

This Critical Chain case study link includes some interesting tracking information. Anyone who has suffered as a result of a client’s internal politics and delays will sympathise with the tale of frustration. Assembling and temporarily disbanding the project team – sticking to the dictum ‘No multi-tasking’ – makes this case a more extreme example but very believable. CCPM is credited with being the project management approach that allowed this project to succeed. The fever chart is a graphic representation of how the Safety Buffer was used. A possible shock for people used to finishing a project in the green, the goal here was to finish in the yellow! The rationale of course is that staying in the green means that your estimates are too conservative!

Via Case Study: A Typical Critical Chain (CCPM) Implementation

The Ten Commandments of Project Management

And James Kerr issued a list of the Ten Commandments of Project Management in Computerworld. And it was good.

I Thou Shalt Narrow Project Scope
II Thou Shalt Not Suffer a Fat Team
III Thou Shalt Require Full-Time Business Participation
IV Thou Shalt Establish Project Review Panels
V Thou Shalt Not Provoke Burnout
VI Thou Shalt Seek Outside Assistance as Needed
VII Thou Shalt Empower Project Teams
VIII Thou Shalt Use Project Management Tools
IX Thou Shalt Reward Success
X Thou Shalt Not Tolerate Quick-and-Dirty Work Efforts

So it is written. So it shall be done. Thou canst revieweth the full list below...

The Ten Commandments of Project Management

Project Effectiveness: Intermingling ...

Tom shares good advice on using easy, controllable factors, such as co-location of project team members to increase productivity. He cites interesting data on the decrease in collaboration as distance increases (measured in feet). ...

... "There's a ton of evidence, including my own research, that demonstrates, for instance, that intermingling project teammates from various functions is an astonishingly potent device for increasing project effectiveness. " ...

Via Tom Peters: The Simple Tools of Behavior Modification ...

Project Management System: Stakeholder Visibility

Transportation industry project management system enables visibility through the project lifecycle to stakeholders. NJIT research team collaborates with users in Houston to customize the system to its needs. A number of installations have been completed across the country. ...

... "The Houston program provides detailed and easily accessible information on transportation projects in the region for TIPs and regional transportation plans. With TELUS, the process is open to citizens and stakeholder groups, not only for project selection, but for tracking project schedules, funding commitments, and related issues. " ...

Via NJIT: NJIT Researchers Help Texans Employ Transportation Technology ...

Leading and Influencing: The Project Manager's Secret Weapon

There's an excellent article by Frank Saladis on allPM about how to lead and influence others. Topics such as boosting your credibility, practicing empathy, and maintaining organizational awareness are discussed, as well as some good tips for engaging team members and obtaining buy-in.

From my experience, these are the things a project manager needs to get right. The rest is just details.

Here's the article. Well worth reading.

Positive Leadership in Project Management – Team Building, Influencing and Leadership By Frank P. Saladis, PMP :: ALLPM Project Management :: Project Manager - Project Management - Information - Forum Manager- PM Tools - Articles -PMI

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.

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

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 Risk Management

Oil production company, Venture Production PLC, uses risk management software to model project scenarios to select optimum schedule while balancing risks, costs, and time performance. This seems a worthwhile approach, when large investment is at stake and time to value is critical. ...

... "Using Pertmaster, Venture's project management team was able to add a risk dimension to plans built in its Primavera P3 scheduling solution. Venture then analysed the schedule-risk of multiple scenario options to look at the most probable outcomes of each, in terms of both timescales and costs. This enabled the best options to be highlighted when considered from both likelihood of risk occurrence and degree of impact and enabled management to take well-informed decisions. " ...

Pertmaster Helps Bring Venture's New Oil Field On Stream ...

Venture Operated Goosander Field On Stream: "Goosander has been developed as a sub-sea tieback to the Venture operated Kittiwake platform utilising two subsea flowline bundles totalling 12 kilometres in length. The bundles were manufactured and installed by Subsea7 from their construction site in Wick and have been designed and engineered to accommodate future production and water injection wells and the potential for re-use on future subsea tie-backs. "

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

Einstein Project Management Tip #5: Imagination Counts

Our next project management tip from our Einstein series regards the need to challenge the status quo----to think out of the box. Consider this quote:

"To raise new questions, new possibilities, to regard old problems from a new angle, requires creative imagination and marks real advances in science."

Of course, Einstein also famously said, "Imagination is more important than knowledge." To a project manager, who's typically focused on things like scheduling, monitoring, reporting, and driving the team to completion, this can be a particular challenge. But it's important nonetheless.

Imagination is required in many situations, including (but not limited to):

• Achieving success when the odds are against you
• Conceptualizing ways to achieve the objectives more effectively
• Brainstorming solution ideas and possible risks
• Overcoming barriers, whether political, technical, or physical
• Improving the cusotmer experience

For some practical advice on building the right team for innovation, see my blog series on Tom Kelley's The Ten Faces of Innovation.

More to come.

ITIL Six Sigma: Future IT Operations ...

The convergence of ITIL and Six Sigma is expected to be the future framework for IT operations. New book explores the use of Six Sigma in the information technology organization. ...

... "Lead Author of the book, Sven den Boer of Getronics said: This long-awaited book on aligning ITIL and Six Sigma is a good start for professionals who want to appreciate how these two approaches can be combined. Proxima Technology played a key role in the book by providing some practical examples to help make it easier for readers to understand. We were pleased to have Linh Ho on the team. itSMF-NL Chief Editor, Jan van Bon was very pleased with the results and added: We have succeeded in finding a great team of authors internationally, experts in both ITIL and Six Sigma. Today, the need for Six Sigma is continuously heard from the IT management field, and we hope to fulfill the fast growing demand with this great best practice. " ...

Proxima Technology's Marketing Director Co-Authors Six Sigma for IT Management Book

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

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

Project Management Lessons from Mars

Brian Muirhead, the project manager for the Mars Pathfinder program, had some good tips to share with Projects@Work this week.

Some key learnings, extrapolated from the interview:

• Innovation and bold ideas are often necessary to meet what often seems like an impossible challenge. The trick is to balance the cost and time savings with the risks.
• A diverse team is key. It's better to have people that are different, with complementary skills, than have a bunch of people who think and act the same way.
• A small core team that can share issues, problems, and resolutions, with one person at the helm, is an effective way to run a project.
• Trust, honesty, and personal committment are traits that need to be prevalent throughout the team.
• Test, test, and then test again. Don't rely on luck. If you can't test using the exact situation, then simulate it as best you can, testing as much as is possible.
• A team is only as good as it's weakest link. It's up to the project leader to identify those people that aren't up to the task and remove them or find an area that suits them better.
• Ensure team members have opportunities to make personal connections and grow.
• A project manager must simultaneously provide the glue (keeping the team cohesive and focused) and the grease (removing barriers).
  
  Here's the full interview...
  
  http://www.projectsatwork.com/content/Articles/232113.cfm

Move Over PMP: PMI Announces Program Manager Credential

As reported in PM Forum, PMI has announced their new Program Manager credential, which looks to be like a PMP on steroids.

Earning the new credential will be like passing the seven trials of Hercules, with education reviews by PMI staff, reviews of experience by a panel of program managers, a multiple-choice scenario-based exam, and an assessment by a team of raters selected by the candidate to rate them during on-the-job program management performance.

Any guesses as to what the new credential will be called? How about PME (Program Manager Extraordinaire) or KOAPM (King of All Program Managers - oops, that wouldn't work for female program managers). Maybe SPM (Supreme Program Manager)? Hey, we get enough jokes about the PMP acronym, why don't they continue the trend and use PMS (Program Management Specialist)?

I better quit while I'm behind.

In all seriousness, it's good that the credential will require such a rigorous application process. With so many organizations virtually guaranteeing "instant PMPs," this one should have quite a bit of prestige.

While the PMP certification assures a solid foundation of project management knowledge, this one should give organizations the confidence that the certified program manager is indeed worthy of managing large programs (although nothing is foolproof).

Here's the full article on PM Forum, where they list PMI's stated qualifications for certified program managers. One might argue that a senior project manager should have the same qualifications (although PMI's FAQ page attempts to distinguish the project manager role from that of the program manager).

PMFORUM, Connecting the World of Project Management PMFORUM Breaking News: PMI INTRODUCES PROGRAM MANAGER CREDENTIAL

5 More Lessons in Leadership

For lessons #10-6, scroll down to see my post "5 Lessons in Leadership" from yesterday.

The following Lessons in Leadership were originally presented at a recent CIO Leadership Conference but are also applicable to PM's:

5. The true test of a leader is how you behave when the chips are down and things are ambiguous - including when no one is watching.

4. Your team is allowed to have morale problems; leaders are not.

3. Leaders require a esnse of history (yes, learn from the past, but understand that what you do matters in the future)

2. When faced with ethical dilemmas, apply 3 tests:

• Newspaper - how would you feel if it was a headline tomorrow?
• Golden Rule - how would you feel if it was done to you?
• Obituary or Best Friend - how do you want to be remembered?

1. LISTEN. One of the most essential leadership skills.

Thanks to Abbie Lundberg, the Editor in Chief of CIO Magazine for the info and insights that she shared in the June 15, 2006 edition. They formed the basis for this blog.

5 Lessons in Leadership

The following Lessons in Leadership were originally presented at a recent CIO Leadership Conference but are also applicable to PM's:

10. Failure is not an option (as per Apollo 13's project leader Gene Krantz)

9. The kind of organization you are in determines the kind of leader you need to be (I'd also add that WHERE the project is in its lifecycle and the level of project experience your team and stakeholders have also matters)

8. A good leader has integrity (e.g., accountable, truthful (including in how you report project status and metrics!), a team player and tough when needed)

7. Don't be lazy. (push beyond your natural abilities - get into the details, get out of your office and talk to people, etc.)

6. Make sure that everyone in your organization can articulate what it is you're trying to accomplish (I've also heard this called "the hymn" (i.e., make sure everyone's singing the same tune, from the same book); if you have a more PC, one-word term, let me know!).

You'll have to wait until later for the next 5...this was plenty to digest in one sitting.

Thanks to Abbie Lundberg, the Editor in Chief of CIO Magazine for the info and insights that she shared in the June 15, 2006 edition. They formed the basis for this blog.

Make or Buy: The Jury is Out

There's a good article in InfoWorld about the age old IT dilemma of "build vs. buy." The consensus seems to be to buy when automating commodity processes and build when dealing with core differentiating processes (a la Wal-Mart). SOA seems to have made the "build" option more palatable.

The worst of both worlds is to buy a huge system and then heavily modify it to match your old systems and processes.

Another up and coming choice for many organizations is hosted solutions. Many companies are doing "all of the above," with a mix of packaged products, in-house offerings, and hosted solutions for a best-of-breed mix.

Here's an excerpt from the article:

Everybody knows that the more standardized you are and the more you buy off-the-shelf, the more cost effective it will be for both implementation and ongoing maintenance,” says Mark Lutchen, former global CIO of PricewaterhouseCoopers, now head of the firm’s IT Effectiveness practice.

On the other hand, executives such as Bob Laird, IT chief architect at MCI (now part of Verizon Business), sing the familiar refrain of in-house
development: “Where we tend to invest is where we can get incremental revenue … or competitive advantage,” he says.

As with many modern enterprises, Laird and team have recast their in-house development efforts within an SOA, enabling them to reuse rather than build from scratch. “Part of the decision is to look at your legacy applications and analyze what legacy you have that still has business value,” he says.

For more, read on...

To build or to buy IT applications? InfoWorld Analysis 2006-02-13 By Polly S. Traylor

Silence of the Project Managers

Have your stakeholders stopped screaming, Clarese?


As reported in Computerworld, a study by a Utah-based training firm found that the biggest cause of project failure is the inability of project managers to effectively confront management and key stakeholders on five major sensitive areas.

Here's an excerpt:

According to David Maxfield, director of research at Vital Smarts, the five
situations include the following:

• Setting arbitrary deadlines and inadequate resources that "set up a project to fail."
• Failing to provide the necessary leadership, political clout or energy for a project.
• Skirting or manipulating the project priority-setting process.
• An unwillingness by team members to support projects as required.
• Failing to acknowledge project problems until it's too late for remedial action.

These findings were based on interviews with more than 800 project managers and over 150 hours of observation. The article stresses the importance of standing up to management, which may seem intimidating, but no worse than what'll happen if you don't stand up and the project fails.

This one's well worth reading, folks. Speaking up early is a key lesson that can avoid many problems later. Here's the article...

Want to kill a project? Keep quiet about problems, study finds

The Making of a PMI Standard; Behind the Scenes

For those who wondered what goes on behind the scenes of creating a PMI global standard, there's a nice writeup in the latest PMI Community Post, which gets sent to all certified PMPs.

In the article, titled Evolution of a PMI Global Standard, PMI reveals the standards creation process, from the project approval and charter through the team selection, standard development, and exposure draft process.

Having served on the leadership team for PMI's new Standard for Program Management and Standard for Portfolio Management, I can say that volunteering on a standards creation project is very rewarding.

It's an opportunity to work with the best in the business and get involved in a large virtual project with people from all over the world. I definitely recommend the experience. Plus you get to earn PDUs if you're a certified PMP.

For those interested in volunteering, here's PMI's Volunteer Opportunity website, which has a link to the Opportunity Page. Tell ' em PMThink sent you.

Project Manager Toolbox: Google Spreadsheets ...

Had a chance to test out Google Spreadsheets today and think they did excellent job with the beta. Feels like working with the client copy on the desktop. Can you imagine maintaining project documents (financial projections, issues lists, etc.) with a team --- collaboratively and securely using the internet from anywhere in the world without needing your own internal infrastructure --- servers, software. I am sure there are bugs and deficiencies, but this is clearly an inflection point in the IT industry. Kudos to Google for getting there first!

Project Manager Toolbox: Google Spreadsheets ...

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

Are PMOs Too Complex For Their Own Good?

There's an excellent editorial on PM Forum about the increasing view of PMOs as "unnecessary bureaucracy" by many senior managers. Unfortunately, many PMOs have created this situation for themselves.

The trick is to focus on streamlining schedules and reducing overhead costs, but in reality the "lets' make our process fit the most complex project we can imagine" approach often results in the reverse---according to the article---as people on normal size projects don't know which items are optional and which are mandatory.

If done right, a PMO can be an excellent way to institute repeatable lean processes, upskill the organization, and remove barriers for project teams. If done wrong, it can appear as a bureacratic burden on the organization.

This editorial is well worth reading for those starting a PMO and looking to avoid being a statistic ...

PMFORUM, Connecting the World of Project Management - Editorials

IT Resource Management: Departmental Priorities ...

Sometimes, departmental priorities can affect the availability of resources for organizational initiatives. Should the portfolio score drive the priority of the work? Should resources be controlled centrally? Resource management is a challenge for the IT organization. CIO explores the team culture and effective techniques for building teamwork. ...

... "Each manager sets his or her own priorities for resources, and one manager's highest priority may very well be another's lowest priority. That, alone, is enough to kill teamwork. " ...

IT Resource Management: Departmental Priorities: Team-Building and Teamwork: Via CIO

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

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 Mapping: Good Reference ...

Here is sage advice and good references on the topic of business process improvement, which includes mapping the current and future states of the process. Ben Graham and team highlight, in this article: The Key to Good Process Mapping (PDF), the importance of organizational alignment and involvement of the key stakeholders of the process: namely the folks operating it. ...

... "There are three essentials that must be handled well to assure good process mapping. ...
1. The operating people whose work is being mapped must supply information for the map and must understand and support the reasons for the mapping. 2. The map itself must be organized in a way that enables everyone involved to clearly understand the process. 3. The information that is assembled in the map must be valid. " ...

Business Process Mapping: Good Reference: Via The Ben Graham Corporation: The Key to Good Process Mapping ...

Process maps are as important as organization charts, according to this article. ...

BUSINESS PROCESS REENGINEERING: A CONSOLIDATED METHODOLOGY (Subramanian Muthu, Larry Whitman, and S. Hossein Cheraghi, Dept. of Industrial and Manufacturing Engineering, Wichita State University): "Talking about the importance of processes just as companies have organization charts, they should also have what are called process maps to give a picture of how work flows through the company. Process mapping provides tools and a proven methodology for identifying your current As-Is business processes and can be used to provide a To-Be roadmap for reengineering your product and service business enterprise functions. "

Project Failure Case Study; Maine's Medicaid System

Talk about a project disaster. As reported in an excellent article in CIO Magazine, the Maine Medicaid Claims System project is a case study of a project gone awry.

The project was undertaken to switch from their legacy systems to a new web-based system to process Medicaid claims and facilitate HIPAA compliance (Health Insurance Portability and Accountability Act of 1996). As a result of the failed project, Maine is now the only state in the union not in compliance with HIPAA.

System problems led to many claims ending up in limbo, leading to hundreds of calls from health care practitioners, nearly 300,000 patients being turned away, several dentists and therapists going out of business, and destroying Maine’s finances and credit rating.

So what went wrong?

Mistakes included the following:

• Deciding to develop an entire system from scratch using unproven technology, while other states built a front-end onto their legacy systems
• Caving to pressure from management to meet tight deadlines with inadequate resources instead of pushing for a realistic plan to begin with
• Failing to notice why other bidders either didn’t bid or came in way higher (a sign that the schedule was unrealistic)
• Hiring a vendor with no experience in developing Medicaid claims systems because they were the lowest bidder
• Not having a Medicaid expert on the team, leading to errors in judgment
• Underestimating the time needed to meet with subject matter experts
• Competing with another major initiative (a department merger) for executives’ attention and resources
• Skipping project management basics (including piloting, adequate end-to-end testing, staff and user training, etc.) due to looming deadline pressures
• Failing to stop, regroup, and analyze the risks
• Taking a “big bang” approach to cutover with no contingency or backup should something go wrong

Management’s response, of course, was to switch program managers, and issue stronger demands to have a smooth system, but none of the changes or demands made much of a difference. Consultants were brought in to prioritize the many problems, but still, the complexities proved too much. It wasn’t until a Medicaid expert was brought in that things began to gel.

Like many project failures, it’s easy to point to the project management (and certainly there are many shortcomings there in this case), but the organization must share the blame as well if it insists on unrealistic deadlines and leads by fear (fear of shareholders, fear of competition, fear of management, etc.). None of these variables can make an unrealistic schedule more realistic.

It's really very simple. Either adequate resources must be committed, the expectations lowered, or a more piecemeal approach taken (or all three, if applicable). In any case, the schedule must be realistic and risks need to be managed.

Here's the full article. It's well worth reading, as are the reader comments.

Maine's Medicaid Mistakes - Editorial - CIO

Team Fun on the Cheap

Is your team suffering from infighting or poor morale?
Do you need a different way to celebrate a milestone on the cheap?

Consider the potluck. Dictionary.com defines the potluck as: A meal at which each guest brings food that is then shared by all.




Although it might be a bit of work for the project management team, organizing a potluck is a cheap way to get the team together. It is especially fun when there are international team members who can showcase food from their respective cultures.

Some tips for organizing your potluck include:

• Schedule it for a Monday. This gives people time to cook over the weekend.
• Create a sign-up spreadsheet with categories like appetizers, entrees, etc., so people can attempt to even the spread.
• For those folks who don't like to cook or don't have time, offer the "bring a staple" option. Every potluck needs plates, utensils, napkins, drinks, table cloths, a clean-up crew, etc. I usually use the "fastest timestamp wins" method for these.
• Book a large enough conference room for several hours around lunch time OR
• If you have a huge team, consider also having people bring in breakfast items (then extend that conference room booking)
• Consider creating a "party favor" for all project team members. We had mugs made with our project name and then filled them with an assortment of goodies in nice party plastic bags (pretzels, candies, nuts, etc.). This was also a team building opportunity because people shared well after the event.

What other ideas do you have for team building events? Let us know!

Study Shows No Consensus on PMOs

Having trouble getting consensus in your organization on the value and structure of your PMO? If so, you're not alone.

As reported in PMForum, the research team that has been studying how PMOs are used has released its interim findings.

The findings, based on the 500 companies studied, show that there is wide variation in the perceived value of PMOs, the structure of PMO's, and in the functions PMOs deliver.

In addition, there appears no be no pattern whatsoever in one industry or region versus another. At the least, it'll make it difficult to come up with any kind of "standard PMO design."

It only makes sense that a PMO's charter could vary based on the culture of the organization, the project management maturity of the employees, the committment of senior management, what the organization is trying to get out of the PMO, and a host of other variables.

Maybe the lack of agreement, and the resulting organizational maelstrom caused when many PMOs are launched, is the reason why two-thirds of PMOs fail. Studies have shown that the PMOs that begin by insuring the success of project teams and providing portfolio management services---and then progress to becoming a center of excellence---seem to have longer-lasting success than those that try to do too much too soon.

Meanwhile, it should be interesting seeing the final results of this particular study. The PMForum report is below...

PMFORUM, Connecting the World of Project Management PMFORUM Breaking News: REALITY OF PMO'S STUDY: INTERIM RESULTS RELEASED

Project Management Ain't What it Used to Be

There's an excellent article in Computerworld about how project management has evolved in the last few years to be much more than the traditional planning, scheduling and monitoring role it used to be (in some circles anyway).

Today's project manager, according to the article, must demonstrate strong business acumen, political savvy, cultural awareness, and soft skills.

A project manager today must be confident discussing a business case and benefits with senior management, negotiating the shark-infested waters of organizational politics, leading offshore resources, negotiating with vendors, resolving conflicts, and much more.

In other words, a project manager must be more of a mini-CEO than a scheduler or team leader. The implications are that a whole different skill set is required.

Here's the full article. It's well worth reading..

The New Project Manager - Computerworld

Application Development Projects: Automated Monitoring ...

FDA uses automation to monitor the performance of distributed application development project teams and provide measures to sustain productivity. ...

... "CAST Application Intelligence Platform is not a burden to the development teams – all analysis is automated. CAST provides the FDA with an automated analysis and monitoring system that delivers productivity benefits to the developers while providing objective information back to management. When selecting a solution, the FDA found that CAST had the only product on the market that can analyze all the languages used in their application portfolio. With the insight provided to IT management on what is happening in application development, and the productivity gains that development can get using CAST, the FDA now sees a way to deliver immediate gains across the organization and turn development into a predicable business process." ...

Application Development Projects: Automated Monitoring: Via Cast Software: US FDA and DTCC Select CAST’s Application Intelligence Platform to Provide Better AD Governance ...

VOIP Voice over IP Project: Team Need Cross Training ...

VOIP project team needs blend of voice, telcomm, and data perspectives to enable success. ...

... "Typically a person or team with telephony or data experience is in charge of a VoIP project. Each tends to know its side of the technology, but not the other. The needs of both have to be met with VoIP. " ...

VOIP Voice over IP Project: Team Need Cross Training: Via CMPnetAsia: Loud and clear ...

Project Management Lessons From the Movies

A few weeks ago, I mentioned the groundbreaking project management training curriculum from Movies Teach Project Management, the organization run by a film critic and a project management expert that teaches project management through the analysis of film clips.

Well, for those do-it-yourself types who are also movie buffs, here's an interesting 2-part article about movies from which we can learn project management and team building skills. I could think of quite a few to add to the list, but it's a great start.

Personal, Team and Organizational Effectiveness: Films Not About Project Teams: Part I; movies, teamwork, management

Project Team Training: Position for Success

With a foundation of training, your project team can accomplish the impossible ...