I realize not everyone and every organization needs a project management office (PMO). Some project management infrastructures just aren't at the maturity level to really make use of a PMO. Some organizations aren't large enough and never will be. And still others never really define their work in terms of “projects.” And far too many fail...but the frequency of their existence is growing.


A 2012 report from PM Solutions indicated that 87% of surveyed organizations have a project management office in place compared to only 47% in a similar study performed in 2000. Yet PMI reported in a study that as many as 68% of all projects fail to some degree. And as for PMOs, I have personally worked in or lead PMOs for four different organizations. One company experienced utter PMO failure…twice…another kept turning over their PMO directors in a never-ending quest for some project management ‘better’ practices, and a third floundered miserably. The only one that didn’t fail was the one I was leading, though unfortunately it was short-lived as the organization itself closed up shop.


On the other hand...really...is this a necessary question for those that do need a PMO? Project offices already have a pretty good pre-defined role in our minds, at least in my opinion. It’s full of qualified (experienced, intermediate, and new) project managers, usually a PMO director who leads the organization, some laid out processes, processes and templates, and space in the organization that is recognized as the go-to office for any project ideas, customer initiatives, etc. that need to be lead by talented project professionals.


Does that sound like I’ve pretty much defined it – in highly general terms, of course? Please feel free to comment and add your own descriptions, definitions and terms here, as this is the purpose of the article.


But what about more? Who’s championing it? How is it funded? Does it handle internal projects, external projects for customers of the organization, and is it led only by the PMO director or is there someone further up who is guiding it on an ongoing basis?


Let’s consider…


External projects and internal projects...they are different but equal. Obviously one is more visible than the other, but I never consider them to be less important. That may be up to senior management or the customer on how it gets prioritized, but a project is a project. All customers are important. The internal project usually has to go through less red tape…most of the time. Funding is always an issue. Most PMOs I’ve worked in or helped start have operated as profit centers and bill out their resources to internal or external clients the same – though rates may be different. That’s another area that needs to be considered – how does the PMO get funded? And what happens if it’s not making enough money? What happens then...are there cut backs in services? Take on fewer projects? Layoff project managers? Up prices and hourly rates of the project management resources charged out on each project? Layoffs? Many financial things to consider.


Who should run the show? Usually this is a PMO director. But it’s not out of the question that it could really be someone else. I’ve had two colleagues write about the concept of a C-level project champion/leader called a CPO. Not C3PO (of Star Wars fame), but CPO as in Chief Project Officer or Chief Program Officer. I personally think it’s a great idea as one of the key ingredients – in my opinion – of PMO success is executive sponsorship/buy-in. Having a C-level PM leader all but guarantees that executive level buy-in.


Don't forget the money aspect – a PMO is not free. Finally, if your PMO is not operating at as a profit center, who is funding it? Let’s say you have six project managers and a PMO director. That’s likely at least $500,000 - $600,000 in salaries – even in today’s cheapened marketplace – that need to be covered. Where is this coming from? Plus travel and training expenses, benefits, etc. Who’s paying for this? The easiest route to take is just bill them back on projects to whoever the project is for, but I’m certain not all organizations do that. How do you cover these PMO expenses?


Summary / call for input


From my standpoint, if your organization is of any decent size and is running “projects”, then it probably should have a PMO.


What about your organization? What role – if the PMO exists – is it playing in your organization? Not just from a face for project leadership, but also in the leadership and profitability of the organization. Please share your opinions or how your company is handling this situation and let’s discuss further.

Tampa goes empty net for the last 1:50 but it didn’t help. Vegas looked great in a 5-3 win over the Lightning ending Tampa Bay’s 11 game win streak and extending our own to 4 games over some really good teams including the last 2 cup winners! Go Knights! And chalk up a goal and an assist for new guy Alec Martinez.

Great win! Go Knights!!! 4 game win streak over teams with a combined record of 144-70-27. Vegas is now 32-22-8 (72 pts) and in first by one point over the Oilers.

As the experienced, jack of all trades consultant, you always want your client to see maximum value in what you're doing for them. You can do that through excellent and timely performance and delivery, hopefully with some measurable return on investment (ROI). But that may not always be keenly apparent or very obvious so looking for ways to add some extra value to your services - preferably for free - may mean the difference between this being a one-and-done consulting agreement and a long term working relationship keeping you involved in several angles and strategic initiatives for the business going forward for weeks, months or even years to come.


To that end, lets consider five ways you can easily add value to your consulting engagement that your client can see and keep with them to remind them of your top performance and value to the organization.


Conduct weekly touch base meetings and regular emails. Clients like to be updated. Staying too far away or too long out of touch may make you über productive but will also make the client über concerned. Or at some point it just might hit them in the middle of a meeting or when asked to get a referral for a good PM service that they haven't heard from you lately and they start to get sweaty. Avoid that paranoia from the customer. It's difficult sometimes to reset it. Keep them in the loop. Have a regular weekly meeting with them and some sort of daily communication (if it makes sense). Send out daily updates to the customer and all stakeholders. Make it like a project newsletter of you want, but make it quick and easy for you to provide yet informative enough to make the daily effort worth it.


Setup their social media presence for free. Go the extra mile. Yes, some of your clients don't have Twitter accounts, a LinkedIn presence or a Facebook page. Do it for them. Create what they are missing, promote it, and post content to it. It only takes you a few minutes to get them started but may mean the world to them. And you never have to tell them how easy it was.


Tweet regularly during the engagement about the company, products, and customer service. Sing their praises to the world - especially your own followers. Potentially, some of those followers could become your client's newest visitors and possibly customers. Great add-on benefit for exposure and hopefully sales.


Provide some short training for client staff. At some point, you'll be gone. You can include in your price some detailed training if, for example, you're setting up a small project management staff or office (PMO). But you could also provide some good mentoring to those who may be taking up the mantle you leave behind. Providing some hands on tool training and "real PM" strategies based on your own experiences and the need of their organization, industry and types of projects they are going to be leading would be extremely beneficial to your customer. You could also be part of the interviewing and hiring process for the staff that will be brought in permanently after your consulting engagement ends. I've done this on at least three engagements and it resulted in additional future work for me with all three of those clients.


Lead short weekly meetings to identify / discuss other organizational needs. You are there anyway and if they needed you for your current engagement then there are probably other areas of need you can help them identify - possibly even areas you can fill the void on since you're a jack of all trades, right? Conduct a 30 minute meeting once a week with your main sponsor or the CEO and select staff you are working with to give them an update on latest progress. Follow that with a 15-30 minute add-on session to talk about any other needs or areas of concern. Offer tips or suggestions on how to resolve or workaround issues they bring up. If the need is too large for that, then make a proposal and present it to your main contact or sponsor outside of that meeting.


Summary


The concept here is to leave the client environment a better and more productive place than it was when you arrived. That's what makes them call you back next time. And if some of that is tied into value added services that they paid little to no money for, then that is going to make a huge impression on that client. This is just a list of five – but continually look for ways to add benefit for not much effort and you'll likely find this client seeking you out more than just this once.

Ahhh…the age old question. Or at least one that seems to come up from time to time. And it’s certainly a question that has frustrated me for a while. When should the project manager become engaged in the project? After the sale? During the sale process? From inception working right along Sales to map out an estimate and close the deal with the client? You could say ‘it depends’, but I’m not sure that’s a good answer either.


About a decade ago I worked for very large aviation and engineering firm where I specialized in managing web projects primarily for internal customers. What that means is I led internet and intranet projects for individual business units in the organization. The whole sales process was mine. No marketing involved, just the internal sponsor initiating a project request and that was my cue to go find out what their needs were, map out some requirements with them, and then turn around an estimate, or price, that we could move forward with. I would sometimes take a developer with me to help speed up the process of documenting requirements and a proposed solution if I wasn’t completely sure, and that in turn would get me to a good price point quickly for the internal client. None of these were multi-million dollar engagements – the largest was probably close to $100,000. But you can imagine then, how informed I was as I assembled my team and began to work with the client on the project. There were no gaps or cracks where information fell through. I had seen the project from inception and knew everything.


Fast-forward ten years to larger projects I was leading for a professional services organization. Sales makes the deal complete with a price and a proposed solution and starts throwing these projects over the wall to me and the rest of the project managers in the organization. We have only the knowledge we can extract from the account manager during a phone call and we have the statement of work…and not much else. No wonder when I showed up at the client site for project kickoff I was usually bombarded with questions and expectations that were different from what I was telling them was going to happen on the project.


It’s extremely important – no, it’s critical – that the project manager in such a situation be part of that sales process. There are too many risks involved – including budget and other financial risks – when the individuals who will actually be carrying the project aren’t part of the team that also prices the project and drafts a solution. The project manager should be allowed to act much more as an engagement manager – running the concept or project request from inception to deployment. When you just hand it over the wall, you create a do-over point where knowledge must again be transferred and you have too much risk for important details just falling through the cracks.


Summary


So I’ll ask the question again, should the project manager be involved in pricing the engagement. My answer is an absolute ‘yes.’ And much more than that – the project manager should be involved in that whole account management process of getting the project request to the ‘sold project’ point with a statement of work, price, draft schedule and a date on the calendar for an official kickoff meeting. By involving the project manager, you have the best chance at not only presenting the right price, but then also ensuring that your project team and the customer will be on the same page when they sit down to finalize how the project will be run during the formal kickoff session.

There is no question that project success is hard to achieve. More than 50% of all projects are usually considered failures by someone to some degree using some yardstick. Surveys generally put project failure rates between 46% and 57%. Not good... not encouraging. Enough to make a newbie or would-be project manager go run and hide under a rock, right?


There are usually three key ingredients to project success in most stakeholder's books: on time delivery, on budget delivery and project customer satisfaction. So what we are discussing here is a major factor in project success. From my experience most stakeholders find a 10% budget overrun generally acceptable. Plus, it's way more easy to correct a 10% overrun if you have to than it is a 50% budget overage The key is to always know where the project financials stand and you do that by reviewing, revising and re-forecasting weekly. Let's go through what I prescribe to as my own 5 key practices to creating and managing a workable project budget.


Reviewing the project pricing and initial high level project schedule. When creating the budget from the start of the project, you're going to want to start with whatever the sales person or account manager left off with. Because that is where the project price came from. Some time and thought and effort has gone into coming up with at least a high level list of requirements, schedule, resource plan, budget and price and it's going to be the project manager's best jumping off point. No reason to start over from scratch... that would only serve to frustrate a project customer who is anxious to get started.


Revising the schedule with real resources and understanding the resource effort load. You may not have a real or full team assigned yet, but you can go back and assess the draft info from sales and derive your resource plan for the project based on what they put together, any statement of work (SOW) you may have, assumptions that were documented, and the draft project schedule and high level tasks that were put together.


Converting the resource plan into project dollars. Next it's time to put those thoughts and draft numbers and historical numbers to use. For example, on a technical project, if you have a Functional Design Document (FDD) to put together and you know that usually takes 60 hours of a Business Analyst and 40 hours of a Technical Lead to put together and produce plus another 20 hours for team member peer review and 4 hours for customer discussion then you know also – in general – the roles and prices to plug into and you'll probably come up with a price of around $20,000+ at the going rates on projects for those positions. You'll probably have a fairly similar price in place for a Technical Design Document (TDD) that the dev resources will actually build a tech solution from. You continue doing that till you've built a fairly reasonable and complete resource plan and thus, have a fairly reasonable and complete starting project budget. What if it differs greatly from the price? You hope it doesn't but it might. You may have worked up to $1,130,000 worth of effort and the project that was sold was for a price of $750,000. Now you have a problem. Ideally, and in most situations on a tech project, the customer is giving an estimate and possibly a “not to exceed” price but sold as a time and materials project. That's best case, but still you have to explain now a potential 51% higher price (($1,130,000 - $750,000) / $750,000) to the project client and help them up off the floor.


Maintaining the budget and forecast on an ongoing basis. Next, the ever important process of maintaining, reviewing and revising the project budget forecast every week. You can put it together and leave it, but that is a definite recipe for disaster. Make connections in accounting, do whatever you do to have quick and easy access to weekly project charging and financial information and plug those into whatever tool you are using as your project financials and project resource forecasting worksheet. For me they are one in the same and my template is a self-built spreadsheet that I still use and have as a free download on my website... you are welcome to it.


Making sure your team is charging accurately to the project. First, let's go by the assumption that we are working in a matrix environment where project resources are requested and borrowed on a project by project basis and that these resources don't officially work for the project managers but rather for department managers (like application development managers for the technical development resources). Every resource wants to appear to be 100% - 120% productive for work and performance review purposes. Every department manager who manages these resources wants the same thing. What does that mean? That means that you – as the project manager – know that each resource is planning to put 40-50 hours on their timesheet each and every week. Those hours have to go somewhere.


We'd like to think that all resources revise their time sheets every day, but we know that isn't true of 98% of the working resource pool. I've never done that as a developer or project manager and I've only known maybe two people who completed their time sheets like that. No, most wait till the 11th hour – often the following Monday when accounting is screaming for last week's time sheets – to document their project charges. They know they worked 50 hours, but can only remember details of about 40 of those hours. Where do the 10 “grey” hours go? To your project if they think you're the project manager who might not notice. Don't let that be you.


How do you keep resources from charging those grey hours to your project? Make a budget review part of your weekly project team meeting so that your team understands how closely you are watching the budget and how important financial accuracy is to you and your project. Do that and I guarantee that your project will not be the project receiving the grey hours to get their time sheets to the 50 hours that they know they worked. It will help keep your project financials in a manageable status and keep the project budget from going way over budget and surprising you some "grey" Monday morning.


Summary / call for input


The budget is critical to successful management of the project. Let your tool or spreadsheet help you, let accounting help you, and let your team help you (make them help you!). your job is hard enough as it is and managing any project budget - no matter how big or small - can be extremely difficult.


Project managers out there - what are your experiences with this? What tricks - and steps - have you employed to make sure you are creating and managing a workable and accurate budget. I've always said a 10% budget overage is usually acceptable and definitely easier to correct than a 50% overage that is usually too difficult and too late to overcome. Stop the bleed before it happens! Tell us how you do that.

Conflict management. It's a nasty two word phrase most managers would rather not deal with. For me it ranks right up there with “performance reviews” and “department budgets” as two of the least loved tasks that those in leadership have to deal with unless they find some poor unsuspecting soul to dump those tasks to. I've been on the dumped side... not sure if I've ever managed to take advantage of the dumping side.


In my book, there are several ways to go about managing team conflicts including just dismissing the conflict for a time and hoping it will just go away. Like when a hockey fight breaks out – the referees let it go for awhile to see how it is going to go and they know that if they stop it in the first period right away it's just going to happen again in the second or third period. Watching for a short while also helps you analyze the situation and may help you deal with it more efficiently immediately when you do finally step in to take action.


Here is my 4 step method to team conflict management and resolution. For lack of a better term or perhaps because I like the applicable acronym, I call it my SLAP method of team conflict resolution. Here is what S.L.A.P. stands for...


Stop. This is the first thing we really must do after acknowledging there is a conflict worth addressing and not something that will just likely go away on it's own. It still may be that way and we can hope it will. In fact, probably 100% of us will allow it to go on for a bit like a the hockey fight hoping some clarity comes from it and all you have to do is ignore it or dole out some punishments. I do this daily as a father with conflicts that arise amongst my littlest six kids aged 10 years and under... you can imagine what it would truly be like if I stepped into every one of those “hockey” conflicts. “He said...!”, but “she did...!”... oh give me a break! But you have to eventually stop it so you can discuss rationally with those involved for the betterment of the project, team and customer.


Listen. Next, we realize there really is a need to step in and take some action to keep our team together and productive and to keep the project from going of the tracks, off the timeline, and crashing head on into customer high expectations. You should further want to pluck your fingernails from their very fingernail beds than have your project customer become aware and get involved in any team conflicts going on. So sit the involved parties down and hear what their coflict or differences are. Give everyone the stage – show no favoritism and take no immediate action no matter how crazy or petty someone's gripe may seem to be.


Analyze and address. So you've sat the team down or if it's really just isolated to two or three individuals you may be able to just sit them down and discuss the conflict. What are the issues? Are they legitimate? Can they be easily solved? If you're working with project only resources and they report to a manager somewhere else in the organization... do you need to take it to their supervisor? Do you need to replace one or more resources on the project team? The last thing you want is for your customer to get involved and go to your CEO because once your customer loses confidence in your abilities as a project manager to control and manage your project team that is a major problem for you. You will likely be removed from the project – and quite possibly the organization – as a result. Avoid this at all costs.


It is also recommend to – if at all possible – avoiding needing to replace any project resources. The more you can do to discuss, analyze and resolve within the team is going to be your best solution because replacing project resources in midstream means time, money, a learning curve, and an explanation to the project customer. You may miss a critical project milestone or deliverable date as a result. You may have to wait on the right resource replacement with the proper skill set as well as experiencing a learning curve. It can get ugly and cause significant project timeline and budgetary impacts.


Push on. Finally, push forward with whatever decisions or actions have been mandated by the conflict. Hopefully, it's as simple as a team or team member discussion to air out any differences, fix and move on. Perhaps one resource thought they were getting low end tasks to work on and wanted what another resource was working on because it offered more productive hours and higher visibility. That may be a legitimate issue and maybe you as the project manager made some mistakes in task delegations that led to it or maybe it was necessary based on skill sets and experience. That's for you to work out. But work it out with the team and when everyone is ready and in agreement - and not before and not prematurely – move forward. Take the proper amount of time because moving forward again before the issue is resolved completely is just asking for it to resurface again later in the project – possibly with an even more significant impact to the project.


Summary / call for input


The bottom line is team conflict on a critical project can be like a cancer and spread throughout the team. It can cause an otherwise productive and effective team to began to distrust each other, produce errors, and cause delays or even refusals to work on tasks together. 3rd grade behavior could become the norm quickly if it's not caught and resolved efficiently, respectfully, quietly and quickly. Don't let this be one of your projects – consider team conflict a risk to manage on every project and discuss it's potential negative affects from the outset. And make your team meetings such that resources feel comfortable discussing any concerns they may have.


Readers – what's your take on this list... these steps? Do you agree? Have you had to deal with project team member conflicts? Anger management issues (those are always fun!), or times when two project resources just simply couldn't be in the same room with each other? What did you do? Please share and discuss.

A project management office (PMO) is an organizational entity usually tasked to centralize and coordinate the management of projects within an organization.
​
A PMO oversees the management of projects, programs, or a combination of both. The projects supported or administered by the PMO may not be related other than by being managed together.


In many organizations projects are grouped or are related in some manner based on the way the PMO will coordinate and manage those projects. The PMO focuses on the coordinated planning, prioritization and execution of projects and subprojects that are tied to the parent organization’s or client’s overall business objectives. The PMO is also responsible for staffing each project with the right personnel to give the project its best chance for success.


PMOs can operate on a continuum, from providing project management support functions in the form of training, software, standardized policies, and procedures, to actual direct management and responsibility for achieving the project objectives. A specific PMO can receive delegated authority to act as an integral stakeholder and a key decision-maker during the initiation stage of each project, can have the authority to make recommendations, or can terminate projects to keep the business objectives consistent. In addition, the PMO can be involved in the selection, management, and redeployment, if necessary, of shared project personnel and, where possible, dedicated project personnel.


Some of the key responsibilities and features of a typical PMO include, but are not limited to:


Shared and coordinated resources across all projects. The project management office acts as the centralized repository for the project personnel who lead all projects within the organization. And while project staff may often come form outside the PMO in a matrix organization, the primary efforts and decisions on staffing those projects – the who and the what – is coordinated either inside or in conjunction with the PMO leadership.


Identification and development of project management methodology. The PMO must be the definer, enforcer and educator of the organization’s project management methodology including all project management best practices that should incorporated, identifying PM standards, and defining how projects are to be managed and reported on.


Clearinghouse and management for project policies, procedures, and templates. The PMO becomes the centralized location for all PM policies and procedures and the development and acquisition house for all project templates, planning documents and other documentation. This also applies to the centralized knowledge database of lessons learned and Q & A type features.


Centralized configuration management. All change management and configuration management concerning projects – including all change order requests – should be originated and managed from within the PMO. This allows for future tracking as well as serving as a reference for similar changes and configuration issues on future projects.


Centralized repository and management for risks. Risks often don’t vary too much from project to project – at least not a large majority of them. With the PMO serving as the central repository for risk management it helps decrease the amount of effort that must be spent on current and future projects for risk identification, risk management, risk avoidance, and risk mitigation.


Central office for operation and management of project tools. As well as defining, enforcing, and educating the corporation as a whole concerning the project management methodology, it is also the PMOs responsibility to select the proper PM tools – including the primary project management software - that project staff will use going forward to manage all projects. Providing stable standardization across the board is important to ongoing success and collaboration.


Central coordination of communication. Communication is the most important responsibility of the project manager and the PMO also serves a critical role in this process. The PMO is the primary source of communication and reporting across all projects – communication both internally to company personnel and externally to current and prospective customers and vendors as needed.


A mentoring platform for project managers. The PMO is directly responsible for educating project managers as well as setting up a proper ‘mentoring’ infrastructure allowing less experienced PMs to learn along side of and from more seasoned project managers.


Central monitoring of all PMO project timelines and budgets. With centralized project reporting within the PMO, the PMO then also becomes a central locale for monitoring project timelines and budgets. This allows the PMO to be the one-stop-shop for information for all executive management and finance departments, as needed, rather than burdening individual project managers with yet another distribution source for their project materials and reporting.


Coordination of overall project quality standards. Finally, the PMO sets the bar for all quality standards in terms of project management, leadership, and performance. It also serves as the go between for the project managers and any internal or external quality personnel or standards organization.