When I learned of an opportunity to sit in on a major NASA project review as a “fly on the wall,” I jumped at it. This seemed like a great way to learn about the new Kepler project. Kepler is a special purpose mission in the NASA Discovery Program, with an objective that the project’s principal investigator William Boruki says is to “explore the skies for terrestrial-like planetary systems around other stars, in order to answer one of the most enduring questions humans have asked throughout history: Are there others like us in the universe?”

Fly-on-the-wall was an experiment in knowledge sharing, offering project practitioners an opportunity to learn from observing good project-related meeting processes as they occurred in real time. This idea surfaced after several senior project managers commented that they had little, if any, training or experience in holding reviews, making presentations, holding team kick-off meetings, or in many other project management activities until they “had to do one.” A common refrain was, “I’d never even seen one!”

To participate as a fly began an interesting and revealing odyssey for me, watching and listening to peer review presentations and discussions from the Kepler-Ground Segment development team to other NASA and contractor managers. These were the key players who would decide how the project would be structured and who would establish a preliminary schedule for this portion of the project.

Now operating in space, Kepler was a joint project between two NASA Centers. Mission control and overall data management were the responsibility of the Ames Research Center, and the telescope and the launch portion were to be managed by the Jet Propulsion Laboratory. The primary instrument of Kepler is a specialized one-meter diameter photometer telescope, positioned in Earth’s orbit to “stare” for four years at a small portion of the night sky, containing over 100,000 stars similar to our sun, and to capture images of Earth-like planets rotating around them. This peer review of the project’s ground segment portion emphasized that Kepler was not a large, complicated project.

I was impressed that the meetings started on time, stayed on time, and even finished a little ahead of schedule, despite a lot of active discussion about the control and management techniques to be employed in the project and who had what responsibility. No fewer than eight separate functional organizations with integral roles in the project attended the meeting, from across three continents including North America. And this was said to not be a complex mission! My hat went off to the Kepler project team for their thoroughness, professionalism and ability to stick to the purpose of the meeting. Some useful tips that I picked up as an observing fly for future use in meetings include:

1. INTRODUCTIONS: Not introducing everyone in the room; only the key players at the main table. Other important contributors, who gave parts of the presentation or contributed to the discussions when appropriate, introduced themselves. Some of these people were high-level representatives who did not seem to mind their secondary roles in the meeting.
2. PURPOSE: Clearly stating the purpose of the meeting at the beginning and, even more important, clearly stating what the meeting “was not” about. This set the stage for efficiency and minimized distracting comments. A facilitator kept the meeting moving along but never “squashed” anyone who had a relevant comment or contribution.
3. OMBUDSMAN: Assigning a key member at the table as an ombudsman with a strong enough personality to cut off discussion when it would be part of a later presentation (not relevant now), or to end comments that contributed little (those who love their own voice) or when it would be more appropriate for an off-line conversation (those who can’t let go but just-might have something important to say). This process worked well and was conducted in a polite, professional manner.
4. ROLES AND RESPONSIBILITIES: A particularly useful chart on one wall, referred to often during the meeting, showed a roles and responsibilities matrix with the key organizations involved in the project, listed across the top as column headings, and the project functional elements as role headings down the left-most column. The row-column intersections in the matrix clearly identified the organization responsible for each of the functions, removing much confusion that might otherwise have occurred.

I believe fly-on-the-wall is an extremely simple but valuable knowledge-sharing technique, easily duplicated in any organization. Tips from observers in well-run meetings can be shared with project managers and teams, and have high potential for encouraging an outcome of project success.

In what ways do you think the  fly-on-the-wall technique can help your projects?

Subject matter experts (SMEs) are generally a very valuable asset to a project manager (PM). However, as a PM, you must be prudent in how much authority and control is given to or taken by a SME. Additionally, you must be aware that a SME can slowly erode your authority, even without a direct confrontation.  When a PM begins to have the authority slowly taken away by a SME, it is called “SME creep.”

I’ve been there. You have been assigned a project to manage and you don’t have experience in the area that you’re about to manage; a project that could make or break your career.  As Frank, the boss, gives you your assignment, you’re wondering if he is speaking English. He is throwing acronyms and technical jargon at you so fast that your head is swimming. However, as if to wish you lots of luck, he reassures you by saying, “Now I am asking Bob, our SME in this area, to give you support and be there to help, if you should need him. Of course, he has his full time job, and so he may be a little slow in responding to you.”

Just great. You’re responsible for the project – assuming you can untangle the jargon into plain English – and someone else has all the knowledge. Your team is looking to you for guidance and direction. Bob is working a 50 hour work week, just trying to keep his head above water. You want to set up a meeting with Bob.

You send Bob an email and say, “What is a good time for us to meet to talk about this project?” You’re trying to be understanding and cooperative. That is a nice consideration. However, you are sending the wrong message to start the project. What you are subliminally saying is, “I recognize your time is more valuable than mine, so I will let you take the lead.”

Some may disagree with my interpretation of this situation, and that is OK. I realize there are SMEs out there that would not take it that way and would be thankful that you where being considerate. Then there are others that would, perhaps subconsciously, take it just the way I presented it. Bob sends you back an email stating that he will be able to squeeze you in tomorrow at 5:30 PM, knowing that the standard working hours are 8:00 AM to 5:00 PM at his office. You realize that you are a salaried “professional” and sometimes (most of the time) you have to work a “professional day” (which means no overtime), so you agree. Strike two for you. By letting Bob set the location, you once again are giving him the upper hand and implying that you must go to Bob instead of him coming to you.

You show up at his office two minutes early. He is on the phone talking “technical speak.” He motions for you to come in. He raises up one finger, indicating that he will just be a minute. So you sit there looking around the room at all the technical posters and books that have multi-syllable words in the title. You glance at your watch and that one finger minute has turned into ten minutes and Bob’s conversation shows no sign of slowing down.

Strike three. Bob obviously does not respect your time or he would have ended the conversation when you walked into the room. You haven’t spoken a word about the project and you have already lost control.

It just goes downhill from here. After you have waited for 15 minutes, Bob finally gets off the call and apologizes profusely. Don’t let that fool you. You begin the conversation by giving him a little background on yourself. He stops you after about two minutes into your opening and says, “Frank,” (your boss), “tells me you’re a little ‘weak on experience’ on this project.” He clears his throat. “Don’t worry, I know enough about this project for both of us.” This is another bad sign. He does not want to listen to you because he thinks he knows everything, and the boss has confided in him that you are “weak” on the subject.

I could go on with this scenario, but that would be just more to read and you wouldn’t get much out it except more ways of identifying that you were in trouble.

Consider this approach: Interrupt Bob and say that you are glad he is on the team. This is very subtle way of telling him he is a team member, not the team leader. Secondly, say, “This meeting has run over the time I had allotted. Do this for me,” (in a friendly tone), “put together a list of the deliverables. Do you know how to do a WBS? After drafting a WBS, would you put together resource requirements with roles and responsibilities, and then a time estimate, based upon your suggested resource requirements, and show me a time line and the critical path? You’re probably the best choice to do this since you are so familiar with the project requirements.”

Wow, what did you just do?! By him making the statement that he knew enough for the both of you about the project, he just said, “I am the only person that knows what to do.” So you loaded him up with enough work to “choke a horse”!

If he is all “techie,” he won’t know how to do those tasks, so he will have to refer back to you for guidance and it will be clear that you have taken back the leadership role. If he does know how to do all those assignments, that’s great; you can grade his papers. In either case, you are clearly the one in charge. Be fair with your evaluation of his work, but make it obvious that you are supervising him, not just taking everything he does as gospel. This will reinforce your authority. If you can, get together a committee that you obviously run and put his work in front of a committee, reinforcing the point that he is part of a team.

As with most everything in project management, this is a “situational” scenario. You must adapt to the personally of the SME and the operational process assets of your organization. I hope you are never put in this situation. However, if you are, you might consider this approach.

Good Luck.

Perhaps the most common environment a typical project manager works in is a matrix organization.  Given this circumstance, a lot of project managers not only have no formal authority when it comes to our clients, but also have limited formal authority within our own company. Often the most successful project managers are the ones who develop a methodology and leadership style that allows them to effectively overcome formal authority limitations.

Typical concerns that arise from limited authority situations are: lack of decision-making power, less responsiveness from within the project team and weaker negotiation positions for potential scope and schedule change requirements, to name a few.

So, is managing without authority an art, a science or a technique?  The good news is that there are effective ways to overcome the situation with all of the above, and you can tailor your approach based on your personal management style and preferences. Of course, the process will require significant effort, continuous fine tuning and a good amount of patience and flexibility.

Established Project Processes
The first and most widely accepted way to control the project is through the project process.  The key feature of this approach is that processes provide the necessary structure for your project delivery. Controlling through the process is more likely to be effective in teams where the processes have been established for some time and have been used repeatedly and consistently through multiple projects.  In other words, when your team members understand exactly what to do and how to do it and have been through the process multiple times, your project runs a lot smoother and situations where a strong formal authority is required are few and far apart.

Another nice thing about controlling through the process is that the project manager’s authority is implicit as that of a person responsible for managing the process.  Clear project documentation will have a significant positive effect if controlling a project through process is your primary management mechanism.

Varying Processes
What if you work in an environment where projects vary significantly, driven by major differences in scope, stakeholders’ priorities and project team structures? If you are a consultant, this situation is probably what you live in. Here, controlling through the process is probably not as effective. If the processes have been developed before you joined the project, you have to learn and adopt them. If those processes are not in place yet, developing and establishing them will take some time.

Controlling your project though metrics may become a good addition to your tool kit.  It is generally accepted wisdom that you get what you measure. Carefully study objectives of a project and stakeholders’ expectations and priorities.  Most people cannot allocate appropriate focus to more than three to four measurable parameters on any particular project.  Pick three or four metrics to monitor that would have the biggest impact on the success of a project and on stakeholder’s satisfaction. Measure, review, document diligently, and publish the results in a way that is visible to the team and is easily accessible.

Leveraging Your Personal Style and Competence
The more experienced project and program managers may also rely on developing and then leveraging their personal leadership style. They sometimes control their projects through influence.  The key to using this approach effectively is competence.  Competence does not necessarily mean knowing more than our team or client. How many times have we all felt that the specialists on the team know more than we do? It is not that they know more, they just know different things.

For a project manager, competence is about being able to successfully and effectively deliver on agreed upon objectives while maintaining a positive attitude within the project team. If you are able to demonstrate competence consistently, you will be on your way to developing a reputation of a great project manager and earning the trust of stakeholders and team members.  If people trust you, they are rather likely to imply you have an informal authority, which is perhaps more powerful than any formal kind.

Every project manager finds a unique way to be successful, whether through different combinations of the above mentioned approaches or by developing their own secret sauce. It is fairly certain that at some point in our careers we find ourselves wishing we had more authority to be able to resolve some situations. So please, do share your experiences with your colleagues. Maybe our gathered experiences and lessons learned will help us collectively better manage with limited authority to deliver project success.

Let’s start here. What successful ways have you discovered to manage with little authority?

I imagine you could survey employees on any day in any company and they would tell you that meetings are the bane of their existence. Too often, meetings are conducted without an agenda or even an overarching purpose. Attendees jockey for organizational position or display blatant apathy, checking email on mobile devices or laptops.

Meeting derailers are well documented and websites abound for coping with them. One challenge is that we work in an information age in which knowledge workers spend their time gathering, analyzing and synthesizing data, rather than producing or manufacturing. In meetings we have a desire to share what we know, rather than work to completion or decision. We all have a data set that we bring to the table and we need the time to process the data that others have before we can make a decision.

One way to manage this confusion is to have “pre-meetings”: touch base sessions with participants to set the stage and gain buy-in and commitment. Of course this means that a one hour meeting turns into a series of meetings; not the way to increase productivity! I would propose that this is the best reason to integrate the technology of a social collaboration tool into your workplace.

I can already hear the groaning in some corners of your organization. “Just what we need,” the CFO will say, “Facebook for work.” The COO will argue that the organization doesn’t need people “tweeting” on the job. This is what we often think of when the topic of “social” collaboration comes up. What if we took “social” of the term and instead called it “enterprise collaboration?” Few people would argue that engaging more people in the conversation, at least more people with relevant information, improves the quality of the decision.

A collaboration tool for business might be the answer to creating productive sharing prior to the decision meeting. Inviting employees to discuss and share adds value by increasing the knowledge and awareness of the participants and giving them time to process and synthesize. Furthermore, the content and discussion becomes a shared database and with proper use of tagging and cataloging, the information is available to the organization speeding the time to productivity. In a workforce that is generationally shifting, capturing this “tribal knowledge” is critical to the organization’s long term success.

The other great advantage in using a tool like this is that it increases the commitment to the decision. Because the members had a chance to weigh in, discuss, process and be heard, the team can come to a joint decision during the dedicated time allowed without the posturing and politics that might normally occur in the formal meeting space.

And finally, for the naysayers who will argue that these kinds of tools don’t add business value, there is plenty of research out there that says otherwise. In organizations that utilize these tools, there is better alignment, better transparency, better community and better results.

I’d like to hear your thoughts: how might your organization take advantage of “enterprise collaboration” tools to support higher productivity? If you are already using a tool like this (in my organization we use Yammer) how is it paying off?

Have we (meaning me, at least) been missing what project management is all about? One of my favorite ways of thinking about the complexity of project management has been to compare it to completing a puzzle where you don’t have all the pieces and need to make some of them up as you go along. Another favorite of mine is to think about it is as if I were a juggler trying to keep several balls in the air (scope, cost, schedule, quality, etc.), experiencing only brief encounters with each important part on some rotating basis. But I am now convinced I’ve been wrong because of the simplistic ways I’ve assumed projects can be understood and managed.

At a recent PMI Chapter meeting I had an epiphany about my distorted approach during the speaker’s presentation. The speaker provided insight into problem solving by not only identifying that there are only six different types of problems and cautioning us that to solve them requires choosing the correct approach for each particular type (http://www.problemsolving2.com), but also that many problems may require using more than one approach.

Project management is one such type of problem where my single puzzle or juggler thinking is insufficient. I now know that it requires a triple problem type approach. These three approaches include the following:

1) Puzzle problem thinking works on most projects to identify the pieces involved (at least I was partially right on this method), the interdependencies of the pieces, the constraints on them (resources, time, quality, etc.), and then working with standard tools (network diagramming, critical path, schedule, etc.) until a reasonable solution evolves or something can be changed to create a more workable solution (crashing, fast-tracking, use of float, etc.).

2) Uncertainties abound on projects as risk. This is where my puzzle and juggler solutions were weak, and need to be applied as part of the solution more than they are in many cases.

3) Dilemmas, however, were the key problem-solving link I was missing from my thinking. Dilemmas result from an imbalance between stakeholder requirements and expectations, and what can be achieved with the time and resources available to accomplish the desired scope at the appropriate level of quality. The dilemma is that you want to do what the customer wants, but can’t do it within the imposed constraints. As the famous “you can’t have all three” has shown countless times, flexibility is required somewhere. NASA’s experience with faster-cheaper-better projects shows the fallacy of demanding all three, treating the problems in projects too simplistically.

In my own work with researchers and scientists on their projects, I made it clear they could demand any two of the three constraints (schedule, cost, quality), but the remaining one belonged to me. And it actually worked with them! I’m now convinced that we can do better in our project management by considering that there are often three types of problems intertwined: a puzzle to be solved; uncertainties to be identified and dealt with; dilemmas to be solved in the best interests of both the customer and the project. Considering all three together will achieve a higher level of project accomplishment and success. I can’t wait to try this, or hear from someone else who has.

How have you managed the complexity of projects?

Editor’s note: This is the fourth and final post in a series about implementing PeopleSoft projects. The other posts in this series are; Choosing PeopleSoft – Is it Right for Your Organization?, Initial Considerations of a PeopleSoft Project and Planning for Your Organization’s PeopleSoft Implementation.

Finally, the project is coming to a close and the team is conducting the lessons learned sessions.  With any project, especially one as complex as implementing a suite from the PeopleSoft cadre of products, learning from someone else’s mistakes may be the difference between a successful implementation and a disaster.  Let’s take a look.

All through the project, you take a “silo” approach allowing accountants (or worse yet, the implementers) to configure the General Ledger and Accounts Payable staff to configure Accounts Payables.  Neither group knows what the other has done and why.

Lesson Learned: Never underestimate the effects and the power behind configuration. Take the time to learn how configuration settings “ripple” through PeopleSoft functionality.  Force your integrator to explain these ramifications to you over and over again if necessary. Never stop thinking about tightly integrated modules.

Way-back-when it was too great an operational sacrifice to pull more than one person from a functional area to lend business savvy, re-engineer business processes, test the system, develop functional manuals and train others. Now there is a grand total of four subject matter experts to train and support 500 end users.

Lesson Learned: Cultivate multiple subject matter experts from the start of the project. No matter how much it hurts, plan a deeper bench from the very beginning. Do what it takes to make this happen. If you don’t make this sacrifice early, more work and pressure is heaped on a single pair of shoulders.  As the project progresses, a single point starts to become a bottleneck that the organization cannot afford.  And in the last few weeks before Go-Live, there is no time to bring new people up to speed to relieve that pressure.

All through the project, functional users have the expectation that any requirement spoken aloud translates to system functionality even if the requirement causes a costly software modification. When the system is delivered, their satisfaction level is directly proportional to the number of their requirements that have NOT been delivered.

Lesson Learned: Establish, communicate and religiously follow a process for requirements management and the software development life cycle.  In it, clarify that all requirements are discussed and verified with the functional team and, once accepted as a project necessity, they are documented and reviewed with the technical team who respond with a technical solution and a time frame for delivery.

It is too much work to keep the regional offices involved, so once a month they get a status update at a general meeting which includes several other agenda items.  As testing and training begin, none of the end users in the regions can participate nor do they understand how to do their jobs when the new system is implemented.

Lesson Learned: Over-communicate to and involve every stakeholder.  A Communications Management Plan (which includes stakeholder identification and management), carefully considered and actively implemented, is essential to ensure people-readiness as the organization implements its new system.

Some team members have been attending status meetings and receive most project communications, but the lion’s share of the work is done by a handful of people (those four subject matter experts mentioned above, most likely). Now these less involved members must be pressed into service during crunch time, but they protest to the point where their management allows them to avoid the work necessary to reach Go-Live.

Lesson Learned: Ensure team members understand and embrace their roles and responsibilities from the very start of the project.  Before the Kick-off meeting, document these roles and responsibilities and establish them as unbreakable ground rules. Communicate them verbally and in writing to the team and monitor the team’s involvement during the project so that members who are not actively participating may be considered for removal from the project.

And now, turn these valuable lessons learned over to the other project managers in your organization.  Keep the tradition alive to contribute to project success.

What are some of the key lessons you have learned to ensure a successful implementation?

Note: This is part 2 on PMI vs. ITIL. Read part 1 PMI vs. ITIL:  How Are They Different Part 1 here.

This part of the comparison is about Information Technology Infrastructure Library (ITIL). I am told that it is pronounced “idle”, like in “the idle rich” or “my car idles badly.” I personally do not like that pronunciation.  It conjures up a vision of people standing around waiting for the go home whistle to sound (does any company do that anymore?).  I and some other authors I’ve spoken with pronounce it like “I tell.” That makes more visual sense to me. I visualize some leader telling the troops what to do and how to do it. The leaders telling the troops what to do and how to do it is exactly what ITIL is all about. ITIL is a framework of Information Technology Operational Organization Structure.

ITIL is a framework of best practices for quality IT Services Management. IT Service Management is defined as the delivery and support of IT services to meet the business needs of an organization. The recommendations of ITIL were developed in the late 1980s (around the time PMI’s PMBOK® Guide was published). ITIL origination was in the United Kingdom Central Computer and Telecommunications Agency (CCTA) which later merged into the Office of Government Commerce (OGC). ITIL has been adopted and accepted as a global standard for IT service management since the mid 1990s. There were predictions in the late ‘90s that ITIL would sweep the IT industry and by 2005 it would be the core practice of any large organization’s IT world; however, when those predictions were made they didn’t anticipate the crash of 2001 and subsequent bad economics for the next 10 years. Had the economy not crashed, we would all know more about ITIL. The adoption of ITL is expensive in both time and money.

I suspect the seeds of ITIL began when portfolio managers began to complain that the IT department was getting too much of the budget and they weren’t getting the value that they wanted. The structure of ITIL is to set up the IT department as an independent business. One of the first projects, which should be treated as a project with all the PMI rigors, is to publish a Services Catalog. A list of reports, online applications, web sites, etc., which the IT department offers to the company and sometimes even outsiders of the company. The purpose is a statement to the portfolio managers, “if you don’t like our prices, check the competition and you will see that we are competitive.” Of course not all companies, because of proprietary and confidential information, have the luxury to go to a competitor; however, if rates are published there can be some comparison shopping. This can be a real advantage to a portfolio manager if the IT is not proprietary or confidential. It will allow the portfolio managers to consider outsourcing to vendors that can take advantage of shared resources with other companies. This can have a very positive effect on the company’s bottom line.

The heart and soul of ITIL is the service desk. In the good old days we called it help desk, but someone decided to jazz it up and call it a service desk because it really does do more than just take “I broke it” calls. The service desk is a Single Point of Contact for the whole IT organization, whether you are a programmer, network specialist, hardware repair or install specialist, manager, change control specialist, configuration management person or whatever. There are several sophisticated software packages and a heart stopping price to help you manage the service desk.

There were two ITIL versions – v2 and v3. V3 is the latest path and v2 is going away or gone.  ITIL has two paths to certification. Both paths begin with the”v3 Foundations” class. The two paths are Service Support and Service Capability.  Both end with the ITIL Expert and then ITIL Master. The Service Lifecycle is a more technical path where Service Capability is more of a management path. Both paths include multiple courses. As you take and pass the exam course you are awarded points, eventually allowing you to sit for the Expert and then Masters Certification. As with the PMP^® certification you must document your experience, which is necessary for the higher certification. Since this blog is a high level understanding, I won’t go into the listing of classes.

With the similarities in the use of process by both PMI and ITIL one would think they would be joined at the hip. Well, the challenge is that ITIL has its own project management approach called PRojects IN Controlled Environments (PRINCE) with the latest version called PRINCE2. The method PRINCE2 is in the public domain, offering non-proprietary best practice guidance on project management. PRINCE2 is a registered trademark of OGC. There are two PRINCE2 qualification levels: PRINCE2 Foundation and PRINCE2 Practitioner. PRINCE2 Foundation level is for those with a requirement to learn the basics and terminology of PRINCE2.

ITIL is a challenge to implement. The scuttlebutt is that you have to try to implement ITIL three times before you might succeed. It takes a great deal of commitment by the organization in time and dollars. There is essentially an organizational chart of roles and responsibilities that must be filled.  These roles and responsibilities are not easy to fill and generally take experienced and expensive employee types; however, with that said, once implemented and maintained well, the organization can be very effective. This gets a little confusing.   For more information the website www.itil.co.uk has been replaced by the Best Management Practice website and the official ITIL website managed by the Best Management Practice partnership.

The third part of my blog will be a summary.

Originally published on Idea.com.

Note: This is the third post in a series on PMOs. Read part 1 What is a PMO and What Does It Do or part 2 PMO Business Value and Impact.

In the previous two blogs in this series we looked at what a PMO is, and the business value that they bring to a company. In this blog, I want to look at the considerations that might help you decide whether you need one. After all, they can cost a great deal of money so you should be sure there is a definite requirement.

First, let’s look at a standard project with a PM, several team leads, and various team members. The planning would normally be performed by the PM and team leads with possible input from senior team members or Subject Matter Experts (SMEs), and the plan would include the three basic baselines – scope, time, and cost, considering the other key elements such as risk, quality, resources, and communications, etc.

When the project goes into execution, the PM will normally have a weekly status meeting where he/she would determine the current status of milestones and deliverables (scope), how well this is being performed compared to the schedule (time), all relevant costs (cost) and would probably review risk. During this meeting he/she can implement corrective or preventative actions as necessary.

Now consider a very large project with several sub-projects. During planning there may be a need for a high level view of scope, time, cost, risk, quality, and resources covering all of the sub-projects. The sub-projects may each have a PM, so the overall PM is now managing a team of PMs plus the overall baselines of the project. This is starting to look like a Project Management team!

Now let’s look at a program with several or many projects. This is an expansion of the previous case, and unless the overall Program Manager is careful, it will be easy to lose control and become a statistic for project failures.

The answer for both of the last two cases is probably a PMO, elevating the functions that spread over multiple projects to a PMO team. This team will consider and evaluate the effects of one project on other projects in the program and, where necessary, institute proactive activities as soon as possible.

Other considerations for implementing a PMO include 1) possible resource efficiency improvements across the program and 2) a much improved change management process that evaluates the impacts of changes in one project on all the other projects before deciding to approve or reject that change.

So where is the line drawn between having a Project Manager and a PMO? A PMO can be relatively small, maybe the overall PM plus the individual project PMs, so although it may not be called a “PMO” it could be the embryo of a PMO. The larger the project or program gets, the more likely the PMO is to include:

• A risk manager to review risk of the overall endeavor
• A quality manager to ensure consistent quality goals and “look and feel” across all projects
• A scheduling manager to create the overall schedule, dependencies, milestones, deliverables etc.
• Other specialist personnel

Costs could be collected and reported at the PMO level as could overall status and progress reports, to give management the relevant level of detail they require.

Another major feature of the PMO is the customer interface, whether for internal or external customers. It relieves individual PMs from interfacing with the customer, but probably more importantly, it gives the customer one focal point of contact for the program rather than multiple individual PMs. The customer will be able to have a coordinated view and assessment of the program rather than having to piece together different reports from each project.

In short, there is a grey area between PM and a PMO and it is a subjective judgment as to when one morphs into the other. One big element of the decision whether to have a PMO or not is cost – both the cost of having a PMO and the cost of not having one (potential project/program failure).

Another type of PMO that can be deployed is at the company level rather than project or program level. Several major companies have PMOs not tied to specific projects, but to act as an oversight for all projects and programs being performed by the company. This type of PMO would normally contain senior PMs and might perform project audits at various stages of a project life cycle. They might define and implement project quality measures, tools, techniques, templates, etc. to be used across the company to provide a common “look and feel” for that company’s project deliveries. These senior people could also provide mentoring for the more junior PMs in the company. This type of PMO will be particularly interested in lessons learned from individual projects to provide improving project ability for a company. If a company does not have a methodology, tools, templates, etc. in existence, the PMO could be the entity to develop, train, and implement these standards across the company. The decision of whether a company should have a PMO or not is again a subjective judgment made by senior management and will be subject to financial justification.

Although this blog gives some pointers as to when you might consider having a PMO, it is a highly subjective judgment based on things such as the company’s risk and quality policies, financial justification, and requirement for improvement of project success over time, among other things.

How do you see a PMO benefitting your current project or organization?

Next in this series we will look at how you might establish a PMO.

When it comes to projects, the classic definition of project success is to deliver a project on time, on budget and within scope. However, I’m not sure that definition is adequate. I think it’s time that we revisit the classic definition of success, at least with regard to projects.

If you’re like me, you’ve seen examples of projects which were delivered on time and on budget with the scope that was defined and requested only to find that the end result is never implemented or used. If the software that was developed during an application development project sits on the shelf and never gets used but otherwise satisfies the classic definition of success, we could say that we delivered a successful failure! After all, what good is the product if the end user never uses the technology or the application that we have developed?

Let’s take a look at the Millenium Stadium built in England. This particular stadium was built for a large event and was finished on time and on budget. Everybody hailed the project as a success when the stadium opened. It held that large event and then proceeded to sit empty and unused for a few years. (Note: the stadium is now used.) Is this project a success? For a while, it did not appear to be so.

On the other hand, we may be aware of examples of projects that have been delivered late and/or over budget but are now viewed as successful. One example would be the Sydney Opera House in Sydney, Australia. When the Sydney Opera House was unveiled, the project was seen as an embarrassment and a failure. The project took numerous delays, was way over budget and had some accidents resulting in deaths associated with it. But over time, this “unsuccessful” project has become the symbol of Sydney and a tremendous success. The opera house is impressive, used and loved.

Especially with regard to IT, we really need to revisit the definition of success. Delivering on time, on budget and within scope is not good enough. Too often we de-scope a project in order to deliver it “on time” and/or “on budget”, so it doesn’t often deliver all of the requirements that were requested. That is fine if everyone agrees to the change and to having a product with decreased scope, but it happens a lot. Also, we often don’t do a proper job preparing the end-user for this new product or service. Maybe we didn’t build a product that fully satisfied their needs after all. That’s a failure on our part. Maybe we didn’t provide appropriate and proper training. Maybe we didn’t give them time to get used to the new product or process or to get over their fears of a new system. Whatever the reason, it is hard to consider these projects a success if the application we developed is not actually being used correctly or at all.

What do you think? What would you propose to use as a new definition for project success? Let me know.

A major difficulty of project management is dealing with the inherent uncertainty involved. There are no perfect project plans, and there is little rationale for expending the time and resources needed to try to make them perfect.

Agile project management is one example that shows how reducing the amount of planning in a highly uncertain environment can provide more opportunities to deal with uncertainty as it arises over the life of a project. Other ways to deal with uncertainty in projects begins and ends with understanding what I call the three basic truths about uncertainty in projects.

I. Uncertainty exists.
II. Uncertainty results from incomplete information, or the unknowns involved.
III. Uncertainty ends when the unknowns are revealed.

Reducing uncertainty depends on understanding at least six key elements about it:

1. Point of view
2. Intention
3. Communication
4. Effort
5. Focus
6. Judgment

1.  Point of View
When thinking about project management, what is the right point of view to take? It depends a lot from where you’re viewing the project. Each stakeholder’s viewpoint is based on what they need or expect from the project.

-The customer and/or user view of what they need
-Management’s view of achieving some desired strategic objective
-The program manager’s view of the contribution to their program
-The sponsor’s view of how well the project is meeting its plan
-The project manager’s view of how effectively and efficiently execution of the work is being accomplished
-The project team’s view from how well they are being supported in doing their work

2.  Intention
Intention is how a project fits into each of these points of view. Due to differences in expectations of the various stakeholders, the total sum of the individual intentions for the project may not be wholly achievable, and some compromise is necessary among the stakeholders. The intention for the project is to try and balance the stakeholders’ intentions by first clarifying them, and then meeting them as well as is practical.

3.  Communication
Communication is the lubricant that makes a project flow smoothly. It is close to being an absolute that all problems on projects are due to some problem with communication. Effective communication begins at the highest levels where a project originates with the definition of what is needed and expected from the project. This need and expectation must be made clear throughout all levels of a project- from management through the sponsor, to the project manager, the team, and even to ancillary participants such as vendors and others involved in some way with the project.

4.  Effort
Effort of course is the dedicated energy needed for project accomplishment. This is not just the energy of the team doing the work, but the energy needed from all of the stakeholders to make a project successful. Effort doesn’t end after a stakeholder’s initial involvement is over; it is the energy continually added to the project throughout its lifecycle.

5.  Focus
Focus ensures that the energy expended on the project is done in the most effective and efficient manner: the right work is being done on the right things, in the right way, at the right time. This requires the project manager to carefully determine, authorize, and monitor the order of work being done, and how well it’s being done in meeting the agreed upon schedule.

6.  Judgment
The unknowns creating uncertainty in a project require making a lot of decisions;, not only in the best interest of accomplishing the project, but also in the best interest of the product of the project during its useful lifetime. There is little to celebrate in completing a project that delivers a product prohibitively expensive to maintain, or with an unacceptably short life. However, it is not only the judgment for decisions of the project manager and team that is involved. Judgment begins with management deciding on which projects to pursue and then following those projects through their development to ensure that adequate support is provided, when needed. These are, after all, management’s projects. Those involved in completing a project are only management’s instruments to accomplishing it.

I feel strongly that incorporating these six key elements into your projects will help to better understand and reduce the uncertainty involved.

On past projects, how did you use these six elements?