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

PM Goes Radical on Agile

Project manager's view on agile methods ...

Product Development Best Practices

Guy Kawasaki on product development ... keep it dicee. ...

Too Much Methodology for Research Projects?

3M depends on new product development as its engine for growth and eases back on the throttle with Six Sigma methods for research processes. It may have over-emphasized disciplined methods in an area where structure can hinder creativity. ...

... "Under Six Sigma, the free-wheeling nature of brainstorming and the serendipitous side of discovery is stifled. Proponents contend such methodologies' rules keep researchers on track and accountable for producing. " ...

Via Design News: 3M R&D

Business Games Teach Project Best Practices

Nothing creates understanding like a good game. Here's a novel approach to disseminating best practice process in project and service management. ...

... "Both simulations are high impact, interactive business games, developed to address the process and cultural challenges of implementing IT Project Management and Service Management best practice. This unique approach to business learning brings Project Management and Service Management best practice to life in the context of realistic and exhilarating scenarios. Participants quickly experience breakthrough understanding of best practice processes and methodologies resulting in improved individual, team and business performance. " ...

Via G2G3: Turkish delight

Agile Scrum Concepts Discussed

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






The Agile Alliance

Problem Solving Methodology

An oldie, but goodie method for solving problems ...



Via BoingBoing

Project Methodologies: Keep 'Em Flexible

Time and time again, I've seen organizations spend months devising the perfect project management methodology, sometimes even building it into their EPM tools, only to find people complain that it slows them down and doesn't add much value.

In many cases, they're right. The problem is that not all projects require every step, and in many cases there are easier ways to accomplish what certain steps are meant to do. Another mistake many people make is forcing task dependencies into the project template, such that design cannot happen until planning is completed, and construction cannot occur until the design is approved, and so on.

While this may be true of some projects, on many others, work does not occur in a linear fashion. For instance, certain segments of a project can udergo development while other segments are still being planned. On agile IT projects, the feedback from prototypes and iterations will often dictate the design, and rightfully so.

When it comes to methodologies, frameworks, and templates, the most effective organizations use one or more of following approaches:

- A methodology and project schedule template that allows project managers the discretion of which steps to apply to their project.

- Multiple methodologies and templates for various types of work, with streamlined versions for smaller or more flexible efforts.

- A methodology that identifies which items are mandatory for all projects versus those that are at the project manager's discretion.

In project management, as in pretty much any field, one size does not fit all.

Agile Tipped?

Have agile methods for software development tipped yet? And, the survey says ...

... "There are two interesting observations about these results. First, although the majority of organizations are applying agile techniques on projects of 10 or fewer people, many are, in fact, trying agile on larger projects. " ...

Via Dr. Dobb's Journal: Agile Survey Results

Vote of Confidence for Prince2

PRojects IN Controlled Environments, Prince2, offers a structured methodology for managing projects. ...

... "Prince2 is growing in popularity across all vertical sectors and is becoming the de facto project management approach. " ...

Via ComputerWeekly: IT Project Certification Options

Financial Services IT Software Projects: Seeking an Edge

Financial firms are looking for methods to accelerate the delivery of their software projects. ...

... "Why so much interest? IT project management is an area many companies are weak in, says Forrester's Cullen. It's the No. 1 gap for all firms. " ...

Via Wall Street & Technology: Accelerate Software Delivery

PMO Increases Project Success Rate

The project management office adds value through consistent methods and discipline to increase the success rate of the project portfolio. ...

... "Board executives often approve IT projects without fully understanding them which is why organizations need to establish a Project Management Office (PMO) ... " ...

Via Computerworld Australia: Project Transparency

Getting Projects Off On the Right Foot: The Pre-Flight Checklist

Something you don't hear much about, but is a critical success factor for projects, is what I call the "pre-flight checklist." As projects are completed, not only is it important to review lessons learned, but it's vital to have a checklist that can be updated as a result. This checklist would be the first thing a project manager would look at upon undertaking a new project.

This is especially true for agile projects, where adjustments are constantly made based on user feedback. Of course, not everything would go on the checklist, but any item that could save time later on a future project is well worth adding. Why reinvent the wheel?

If warranted, there could even be a checklist for various types or categories of projects.

This checklist is different from a pre-project assessment (another underrated tool), where preset questions pertaining to objectives, risk, value, organizational alignment, and more, can be asked.

As the adage goes, projects fail at the beginning, not the end.

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

Virtualization: IBM Intel Collaborate

IBM, Intel collaborate to further the advancement of virtualization technology. The two companies are working on benchmarks, sizing tools, selection guides, etc. to simplify the process of virtualization design for IT managers. ...

... "One of the first tools to emerge from this joint initiative is a new virtualization benchmarking methodology called vConsolidate that runs multiple instances of consolidated database, mail, Web and JAVA(1) workloads in multiple virtual CPU partitions on Intel-based System x servers to simulate real-world server performance in a typical environment. IBM and Intel are contributing the vConsolidate methodology to an industry standards body for consideration. ... " ...

Via IBM:IBM and Intel Initiative Accelerates Virtualization on Multi-Processor Servers

ITIL Service Delivery Software ...

Software category continues to improve at ITIL service delivery processes ...

... "Targeted at distributed and disparate environments, Vigilant's Get Aware Suite offers a complete set of comprehensive ITIL based processes for service delivery and incident management. The foundation of the enhanced suite is a methodology based on results-oriented processes that assist IT organizations in correlating information and diagnosing root causes." ...

ITIL Service Delivery Software: Via Vigilant: Vigilant Technologies Enhances Powerful Suite for IT Performance and Operations Services ...

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.

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

PMO Process Primer

Last month, I mentioned a four-part series on Projects@Work about establishing PMOs. The first installment was on defining the role of your PMO up front.

Not sure what took so long for the second installment, but it's finally here and worth the wait (maybe it's a monthly series). This installment talks about the types of processes your PMO might undertake, and offers some food for thought with each process area. According to the article, a PMO might consider:

Project Processes (including demand management, approval, portfolio management, project/application lifecycle, and risk mitigation)

Analysis Processes (including business analysis, business case development, and process redesign)

Planning Processes (including planning and tracking, and capital planning and budgeting)

Administration Processes (including methodology management, training, tool development/ownership, and knowledge management)

To date, this series is an excellent primer on PMO startups. It's insightful and obviously written by someone who has had some varied experience in PMO implementation. I'm looking forward to the remaining two parts and will be sure to post the links here.

Kudos to the author, Ted Stephens, an associate principal at Intellilink.

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

PMO Success Story: A.G. Edwards Case Study

There's an excellent article in CIO Magazine this month showing how A.G. Edwards reinvented its PMO to bring their projects to an 88% success rate (from about 50% originally).

Some key lessons:

• They created a 25-step project management high-level framework of just the high level activities common to all projects. They didn't inflict a detailed application development methodology and left the "how" flexible, as long as the "what" was satisfied. At a more detailed level, they used Primavera for project tracking and dashboard metrics.
  
• They provided leadership training to boost the confidence of their PMs
  
• They moved the project managers from the PMO to the functional areas to encourage collaboration and better align the PMs with the business.
  
• They offered project planning services to assist the distributed project managers with using the new framework effectively (allowing them to use the planning tool of their choice, be it Excel, MS/Word, or a whiteboard). The 25 framework touchpoints, however, are common to all projects for cross-project comparison purposes (I assume enabled in Primavera).
  
• They redefined "success" as "projects that deliver business value." This gives customer satisfaction and business value even greater priority than being on-time and on-budget (note: they still improved their schedule and budget statistics anyway).
  
  This is the essence of the new model and bears repeating. The customer defines success. Under this model, it's quite possible to have a project that is late and over-budget and seen as a raving sucess.
  
• They tirelessly met with stakeholders in individual and group settings to offer the benefits and ask for their support. They used a subtle soft-sell approach with the "bad actors."
  
• They first involved the PMs receptive to new ideas as part of a pilot and them used them to "spread the gospel"
  
• They measured success rates and publicized them in quarterly reports to senior management.

These are all powerful and valid ways to make a PMO successful, and are philosophically aligned with the Service Oriented-Project Management (SOPM) model I've been developing. In this case, these changes collectively served to boost IT's credibility at A.G Edwards significantly.

Here's the full article. Don't miss the sidebar "8 Steps for Improving Project Management."

When Failure Is Not an Option - Editorial - CIO

IT Strategy: Customer Focus SOPM ...

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

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

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

SOPM; A New Project Management Methodology

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

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

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

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

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

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

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

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

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

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

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

More to come.

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

Service Oriented Project Management (SOPM); Bridging Three Worlds

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

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

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

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

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

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

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

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

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

Intellilink shares method for calculating the overall risk on a project portfolio. It is critical to assess the risk of the project portfolio to understand trends and also to determine if additional risk is appropriate, as higher value opportunities are usually associated with greater risk. ...

... "Intellilink, a boutique consulting firm specializing in automating knowledge worker organizations, hosted a workshop outlining its innovative project portfolio risk calculation methodology at the 4th annual IT Financial Management Week 2006 conference at the Wyndham Miami Beach Resort, Miami Beach, Florida which ran from April 3 to April 6. The workshop, which was oversubscribed by nearly 40% of pre-conference registration, presented a simple and practical methodology for calculating the risk of an IT project portfolio. Titled IT Portfolio Risk Management: A Methodology for Calculating the Risk of Your IT Portfolio, the Intellilink workshop was jointly lead by Intellilink's CEO, Patrick Boylan, and Managing Director, Fumiko Kondo. The risk calculation methodology was developed in response to organizations expressing the need to improve their understanding of risk across the IT portfolio. " ...

Project Portfolio Risk Management: Via Intellilink: Intellilink Hosts Project Portfolio Risk Calculation Workshop at IT Financial Management Week 2006: The firm's innovative project portfolio risk calculation methodology was well received by a full house of senior IT financial executives ...

ITIL Implementation: Multi-Year Journey ...

With all of the hype surrounding ITIL these days, it is easy to forget the effort required to make the full-scope transformation. Expect to spend multiple years to fully implement ITIL across all IT processes. This firm set the record in 12 months. Most of us are likely to take much longer, depending on the level of maturity that we are starting from. ...

... "Using Nexio's project team, methodology and web process manual, Domtar deployed 21 processes within 12 months, a feat never achieved in the history of ITIL. By doing so, Nexio breaks the established paradigms by proving that an organization does not have to spend years and millions to achieve sustained, repeatable and economical IT service excellence and quality. " ...

ITIL Implementation: Multi-Year Journey: Via Nexio Technologies: Nexio's Domtar project awarded ITIL project of the Year ...

PMOs; Where's the Value?

A contributor to eProject's eLounge mentioned this excellent article from Chief Project Officer. It's written by Tom Westcott, founder of Project Solutions Group. Several years ago, I saw him speak on scheduling techniques at the PMI Delaware Valley Chapter's Annual Workshop, and was very impressed with his dynamic style and pragmatic approach.

In the article, Westcott talks about how PMOs must demonstrate value if they are to survive, and offers some good tips on how to do just that. Specifically, he says they must create strategic alignment, deliver real value, and communicate frequently.

Here's an excerpt on what he has to say about delivering value:

PMOs must deliver value to survive. Value is not templates, tools, methodology, processes, training; these are means to driving value. Value is gaining efficiencies, achieving cost savings, increasing customer satisfaction, reducing time-to-market, increasing revenue and profit, reducing deficits, or increasing competitive advantage. Too many PMOs wrap their whole mission and existence around the services they provide instead of their impact on the business. Executives buy value.

Too many PMO directors are former project managers who see their role as project management evangelists. This
leads to a myopic view, and often they are ill-prepared or unable to work strategically with executive management. PMO directors need to speak and think in business terms, financial and organizational. Nix the "project-management speak." How does this project benefit the organization and support our strategy? And how can we get it done as quickly and inexpensively as possible? That's what they care about.

For the full article, read on...

Chief Project Officer: PMO or Bust?

Project Management Checklists; Expand Your Toolbox

AllPM is one of the more content-rich project management sites. And best of all, the tools are all free.

One of the many useful areas on their site is their checklists section. I particularly liked the Consultants Methodology checklist, which I think is valuable for any project manager.

It's concise, simple, and correctly focuses on the up-front goals and solutions analysis, before getting into the actual exectution of the project. It's a 60,000 foot view, which is just what's needed before getting into the fine details.

Check it out...

ALLPM Project Management :: Project Manager - Project Management - Information - Forum Manager- PM Tools - Articles -PMI

ERP Project: Keep Eye on Details ...

Firm publishes report on approach to challenging ERP business transformation projects. Current marketplace conditions are impacting the quality of ERP implementation talent even in the context of a strong methodology. This requires the client company to pay close attention to the project details. Be on the look-out for: Lack of transparency, limited bottoms-up planning to complement the top-down methodology, no iterim integrations with legacy systems to bridge gaps during the implementation, and missing current state analysis.

... "Based on its work helping numerous companies pull errant ERP projects back on course, DiamondCluster has identified circumstances that endanger projects and offers specific steps that can keep companies moving in the right direction. " ...

ERP Project: Keep Eye on Details: Via DiamondCluster: Red Flags Can Signal That ERP Integrators Are Off Course According to New DiamondCluster Report: Studies Show Many ERP Projects Still Run Significantly Over Budget and Behind Schedule. New DiamondCluster Report Explains Why and Offers Advice to Keep Efforts on Track ...