We all make mistakes. We may act on incorrect or insufficient information when making our mistakes. Or we just may act on our own poor judgement. Or we may get bad advice from someone else that results in mistakes. We may also just act irrationally or make a rash decision that leads to mistakes. Whatever the cause, mistakes are likely our own fault – at least in terms of how I'm looking at it for this article. Even if we are acting on bad information from others, the steps forward we take are still our own mistakes and we must own them. Especially if we are in a position of authority – such as the project manager leading a major project engagement. Passing blame really isn't an option. Not for a true leader.


There are literally hundreds of mistakes we could consider for project managers. For me, I've narrowed most down to three key underlying factors or sources and that's what I'd like to focus on for this discussion. Please think about your own experiences as you read this and feel free to share your own thoughts and opinions...


Poor communication. Good, effective, efficient communication is the number one responsibility of the project manager. I'm not sure you'd find that in every text book or how-to on project management, but you would if I wrote it and you'll find it mentioned in a few hundred of my articles, eBooks and videos. The communication buck starts and stops with the project manager. If communication on the project is poor, sporadic, inconsistent or going to the wrong people, then the project manager is at fault and needs to change his own practices. Or, if it's happening with someone else on the project – he needs to regroup the team and set a new, corrected communication plan in motion. Ideally, a formal communication plan would be put together at the beginning of the project identifying the PM as the main point of contact and the primary source of information gathering and dissemination on the project. This plan would also identify all the key stakeholders on the project and list their email, phone and Skype, etc. contact info and would also document when, how and where ongoing key project meetings would be happening. Short of that – because something like this is not usually a deliverable on smaller projects – a spreadsheet will do the trick...as long as it's made available to all key project stakeholders and revised as needed.


Letting the customer get away. If the project customer is not available then problems can mount on the project. The PM needs to make sure that the customer is engaged from beginning to end on the project. When the project sponsor - or whatever key point of contact has been determined on the customer side of the project - is unavailable for periods of time, they may be getting sucked into their day job responsibilities. We have to remember, this project is a one-off task for them – they likely have other major responsibilities to worry about and be involved in. Don't let them get away – they are needed for project information and decision making. Keep them engaged by keeping them assigned to tasks on the project. And it's ok if you make things up along the way...you must ensure that you have at least some of their attention throughout. Give them tasks that they are expected to report on at every weekly status call. No one likes to look like they are dropping the ball, so that should keep them more frequently engaged on the project and available to you when needed.


Lack of budget awareness. The project manager who does not stay on top of the project budget is in for a big surprise down the road. I've never known a project to stay on budget unless some significant effort and oversight is put into it. I always say that a project budget that is 10% over is much easier to fix than one that is over by 50% and going out of control. Once you've reached that status, it's probably too late. But if you stay aware and review and revise the project budget with project actuals every week you are far less likely to lose control of the budget. And going over budget is one of the key failure points in project management – don't let it happen to you.


Summary / call for input


This is my list...these three are the primary mistakes that I've seen or experienced to cause major problems on projects. These are underlying problems, but still very fixable if corrective action is taken early on.


What about our readers? What do you personally see as major mistakes that project managers make? Let's make a list and discuss...

In this age of cloud computing, web-based project management and collaboration software, and large corporations with geographically dispersed employees and customers, more and more projects are being run by virtual teams with project managers and team members working from home or satellite offices. While these can be very green and cost saving options, they are not without their challenges. Delivery team and customer time zones must be considered, communication must be streamlined, the right collaboration tools must be in place, and the project team must be staffed with experienced professionals who are self-motivated and focused on project delivery.


I recently led a team of like-minded and focused professionals on an entirely remote analysis and selection project for a large public-sector entity. At the end of the first key six month phase of the project, I had sent and received more than 4,000 emails, conducted 112 conference calls, had vendors put on more than 40 online demonstrations, and not one dollar was spent on travel or printing or delivery of materials of any kind. Green? Yes. Economical? Very! My new Macbook got initiated the hard way, but it’s still working just fine….


Virtual teams sounds like the way to go, right? Organizations could be saving millions of dollars and everyone can be working in their shorts and t-shirts all day. But there are the challenges that I’ve already mentioned above plus more. The bottom line for the project manager is this – how do you keep your globally dispersed team working together and staying focused on like-minded efforts to bring the project to a successful end while they are also still facing the challenges of often working on multiple initiatives at once? How do you garner their complete cooperation? How do you ensure they don’t go off on tangents with you not constantly looking over their shoulder?


I generally use the following five techniques or methods to keep my remote projects and teams running smoothly:


Setup a communication plan from the start


As much as we all hate producing the formal plans during the initial planning phases of the project, they can be beneficial. And since I firmly believe that efficient and effective communication is the top responsibility of the project manager, I likewise believe that a formal communication plan is a key document to have in place as the project kicks off. The communication plan says when and how key communication will happen on the project, when status meetings will take place, and it identifies who is responsible for each type of communication or meeting. It keeps all parties accountable for good, effective communication and lays the ground rules for the entire engagement.




Use a collaborative PM tool


The next step in building a cohesive team is selecting and using a PM collaboration tool that promotes participation, updating of tasks that team members have direct responsibility for, and serves as a quick communication tool that allows for status updates and discussions among team members beyond the usual email experience. That can be a web-based, cost-effective tool or a combination of a PM tool and a social media offering with a private group created for your project team collaboration. Whatever works for your project is fine, but it must promote ongoing communication and cooperation among team members.


Hold weekly internal team meetings


It’s not all about status meetings with the customer. Before that can even happen you need the most up to date information from your team that you can possibly get. To that end, I always conduct weekly internal team meetings 1-2 days in advance of a formal weekly meeting with the customer. That allows me to get status info from each team member, prep everyone for key discussion points during the customer call, and have all the info I need to get the customer a revised project schedule and current status report that will drive that formal weekly discussion. No surprises and a smooth customer meeting is usually the benefit from this effort.


Expect participation from each member on formal customer calls


The internal meeting gets me everything I need for the customer status call, but it also prepares the entire team. And expecting everyone to participate on the call in their area of expertise keeps everyone focused on what the tasks at hand are at any given moment.


Meet for major phase kickoffs


Finally, on most remote projects it’s wise to bring the entire team together for major phase kickoffs. Certainly the initial project kickoff is important – though the entire team may not be fully assembled at that point. Large, long term projects usually have several major phases where you have an opportunity to bring the team together with each other and the customer. It’s a good time to regroup and refresh and gain new focus on the next phase of the project.

Did you ever have one of those project customers come to you with an initiative that really has no boundaries or definition yet? Sort of a taste of “we'll get there when we get there.” Basically, you're assigned to a project that really isn't a project yet and working for a customer who doesn't know what they need...at least not yet. Maybe you thought you had a project, maybe you have a statement of work (SOW) in hand and even kicked off the project with that information, but when you started really work with the customer you find out that everything was not as it seemed.


So what do you do? You want the customer to be happy…but at any and every expense? No. What can cause you to be stuck in this situation? In my project management experience on my own projects and from discussing PM issues with colleagues, it usually comes down to one of three major situations that have come about to put you and your team in this position: Poorly defined requirements, vague acceptance criteria, or weak project leadership. Let’s look at each of these and discuss ways to either avoid or combat these problems as they arise.


Poorly defined requirements or very incomplete requirements. If you’ve taken over a troubled project in mid-stream then you really can’t take the blame for this one. It’s just important that you recognize the problem for what it is early enough before the project budget gets into too much trouble. If it’s been your project since inception, then you have no excuse – you allowed the engagement to move forward from the planning phase without getting good requirements.


Either way, you’ve now reached a critical point in the project where it’s causing problems. You can’t get the customer to move forward because they don’t seem to know what they want and you can’t tell them what they want because the requirements aren’t defined well enough.


You and your team must revisit the planning phase with the customer and analyze the existing requirements. Are there gaps in requirements? Is there critical detail missing that would help you and your team – and the customer – make some of these key decisions that seem to be holding up the project progress?


The best thing to do is to rework the schedule using your online project management software tool and add one to two weeks of additional planning time to fine-tune the project requirements.


Undefined or vague acceptance criteria. Another problem that can cause this type of stalemate with the customer on a project can be vague deliverable acceptance criteria or vague milestone signoff criteria. If you don’t have the criteria set in place that lets everyone know when something has been successfully delivered, then it can sometimes be very difficult to get customer agreement and signoff when that milestone arrives in your web-based project management software schedule.


If poor criteria exist – or, worse, if no criteria exists – sit down formally with the customer and come to an agreement on what will constitute an appropriately met milestone or deliverable. It may not be easy, and it may require some negotiation, but accomplishing this now will help you and your team avoid these problems for the rest of the engagement.


Weak leadership. The final cause of the wishy-washy customer can be simply poor or weak leadership at the top of the project – and that’s you. Maybe you’re not being stern enough with the customer when it comes to making key decisions on the project. Maybe you’re being too laid back as your team is finishing up critical deliverables and you’re letting details slip through the cracks. Whatever the problem, it’s critical that you get a backbone now and start enforcing the deadlines that were set forth in your project management software schedule, or your project is going to slide further and further off schedule. It’s never too late to take control of the project – unless your senior leadership has already made the move to replace you due to poor project leadership.


Summary / call for input


These types of situation never end well unless you take charge, get detailed requirements in hand, rein in the project customer, figure out exactly how to get the real work on the project accepted and signed off and be the leader you need to be.


Have you ever faced this type of customer or this type of project. I have on a couple of occasions and it is no fun...I lost lots of sleep over these issues. What did you do to “fix” this situation and turn it around? Please share and discuss.

I know this question sounds like a crazy one to ask on the surface. Every project – in it’s details – is different, I know. Even two projects implementing the same technology – maybe even with the same PM and technical team involved - will be different to some degree. But my real question is this – are all projects basically and fundamentally the same? From a project manager standpoint, do we really run project A different than project B? Do we do the same things – just in different detail – on each project (or at least the things we know are helpful and successful and aren’t contributing to ongoing project failures once we learn our lessons)?


The answer, I’m afraid, at least for me, is still not clear cut…but it is one I’m curious about and would welcome everyone’s thoughts and input.


Here’s my take… There are some fundamental things we SHOULD do on every project. Period. These are…


Gather initial project info. Get what you can from whoever initiated the project or closed the deal or whatever. An account manager, the project sponsor (or both), executive management, your PMO director…whoever might have meaningful information, requirements, estimates, mockups, etc. You need that critical information to start the real planning on the project and putting together a useful project schedule.


Get a team together. Now, if the project is small…like maybe a data transition and you have the knowledge and capability to do it all yourself, this may be a one-person team. Otherwise, you’ll need to gather resources based on the skill sets you need.


Hold a project kickoff. Sometimes this has to happen before you’ve assembled a team and sometimes after and sometimes it may just be you and the project sponsor. However, this meeting is critical to set proper expectations, finalize milestones, understand assumptions and plan for more planning and plan for the when and how the work will happen on the project.


Weekly status meetings and reporting. I don’t care how formal you make your status meeting – it can be a one-on-one call with the project sponsor that last for five minutes if that’s all it takes, but it must happen every week like clockwork. If communication falters, that’s when the project can start to come unglued and project customer satisfaction can begin to decline. Don’t skip the regular meetings and status reporting, even if there isn’t much to report. Of course, on larger projects this status meeting and reporting process will be more formal, but it still needs to happen…every week.


Communicate well and often. Effective and efficient communication is job one for the project manager no matter how big or small or detailed the project is. It’s not just about the status meetings and status reporting either – it’s about all project details, task management issue management, risk management and anything relevant to the project that needs to be efficiently disseminated to the project team members…and customer…in a timely fashion. And that must start with the project manager.


Conclusion


So I’ve convinced myself through this article that yes, all projects are basically the same at the core. You may toss out some steps along the way depending on the size of the project and the budget and the length of the timeline. But the things that are listed in this article are the building blocks to a successful project – some basic best practices. And they need to happen – even if they are brief on small projects or take weeks on large projects – they need to happen on every project to keep the team and customer engaged and the project moving forward.

As project managers we all have those times that come up where one project or activity takes up most or all of our time. It’s a PM way of life – it can’t be helped. And when that one project jumps up and takes all of our energy, resources and available time, it becomes so difficult to keep track of the other things going on and the other work we have on our plate – which is often other important projects leading other team members who need us and engaging other project customers who are looking to us for project leadership and direction. Yes, it would be nice if we could shut out the rest of the world and focus on the one project that needs 110% of our attention right now, but we can’t do that. We must still provide adequate oversight of the other projects we have going on – otherwise we run the risk of failing at every project we are currently leading.


So, when one project is looming so large and experiencing issues that require just about everything we have to give right now, what can we do to ensure that we aren’t dropping the ball on the other projects we are managing?


Generally, I employ one of these three actions or steps – depending on the overall state of each project and depending on how dire the situation is for the main project in question…


Assign someone as a temporary point person on the troubled project. If the best thing to do is to offload the problematic project, then assign a trusted resource from the current team to take over for a couple of weeks or so while you focus your attention on the several other projects on your plate to get them back up to date and in good standing with the project customer. I don’t recommend offloading the problematic project, though, if the needs or issues are big. By doing so on such a project, you may send a very negative message to the project customer and risk losing further ground on the project by turning project management duties over to individuals who aren’t PMs and are busy just trying to fight the current issues on the project. In this case, the next option is a far better choice.


Assign temporary leaders to the projects in good standing. Likely, this is the wisest choice and this is the one I’ve actually used the most when faced with this type of situation. Ideally, meet with the project team on each project and brainstorm on the best way to attack the situation – possibly even incorporating the use of mind mapping software to help you plan the temporary move of responsibilities. Then take action by offloading the regular weekly PM oversight duties to someone else on the project team – often it’s the business analyst. Stay involved as much as possible to make sure day to day management of the project is happening, but by assigning someone else to be the primary PM contact and point person for a couple of weeks or so can help you free up enough time to focus on the big issues facing the project in question and help you get it through the valley that you’re going through with it at the moment.


Get temporary outside help for the troubled project. This is my least favorite of all three because it is costly. And, it brings in someone new to the project who the customer is unfamiliar with and it can send a message to the customer that things are really bad – when they really may not be that bad. Anything that causes the customer concern or unrest is bad. But if you have no other choice, this may be the proper action to take. Go to senior leadership or the PMO director – whichever is appropriate for your organization – and get an additional or temporary PM assigned to the project to assist. And if the issues are such that what you really need is more of a different position – say a business analyst or technical lead – then go for that type of resource. But don’t keep them onboard any longer than necessary because they will be a fast drain on the project budget.


Summary


No one likes to admit defeat on a project and we usually won’t have to even when times seem the darkest on a project engagement. Recognize early enough that you either need a little extra help or you need to re-focus more time to a given project and shift resource responsibilities accordingly. Done strategically, you can help ensure that you cause the least amount of project and customer disruption. The key is to make sure the customer sees that any change is positive and that you’re still focused on the success of the project.

Most of what I like to write about is from the project manager’s perspective. And I always maintain that communication is the #1 priority of the project manager. Project success, customer management, team oversight, leadership, budget management, and scope management are all very key responsibilities of the project manager – but each one of those starts with communication. But what about those individuals who aren’t part of the immediate project team?


Equating the project management structure to our own familial dynamic…what about our cousins, our nieces and nephews, aunts and uncles...those ‘family members’ who aren’t necessarily part of our daily lives. How do we need to communicate with them? How much do we need to communicate? How often? To what level of detail? And can/should some of them be excluded? I’m talking about our project stakeholders as a whole…and some of those aren’t the ‘involved daily’ type of stakeholders. They’re more like the distant cousin or uncle you see once a year. What do they need to know?


You’re immediate ‘family’


There’s no question that certain project stakeholders need to know everything. These individuals need access to the latest and greatest project information whenever you can provide it – and that should be weekly for most of them and daily for a small handful. Your team and your project sponsor and their close team/contacts need regular weekly project communication and updates and as needed updates when you or they deem them necessary. Usually the internal weekly team meeting with your project delivery team and the weekly status call/meeting with the project customer and your delivery team will handle most of the communication that needs to happen with these individuals. Of course, the weekly delivery of a project status report, a revised project schedule showing how the project looks ‘today’ and any revised issues lists, risks status, and budget information that was deemed necessary at project kickoff time needs to also happen as part of this regular communication to this close knit project stakeholder group. Don’t worry, if the communication process is in place as it should be, any project stakeholders who are this close to the heart of the project will feel very comfortable reaching out to you for any project status information they need at any given time.


The distant relatives


After that you have your ‘extended’ family. The stakeholders who have an interest in the project and are potentially affected by its success or failure in some way or may have employees involved in the project. These individuals are on more of a ‘need to know’ basis. They don’t need every update and will feel overloaded with information if they are getting a weekly email with a revised project schedule and status of all issues, risks and financials. They don’t want that, they don’t need that, and won’t know what to do with it. They will ignore it and then likely miss something that you would have otherwise liked them to pay attention to. For this group it’s better to provide them with a customized, high-level project status report that goes out once a week or maybe even just once a month that greatly summarizes what’s been accomplished, what’s in progress, and what significant tasks are scheduled for the next week or month (depending on the reporting period you’ve decided on for communication to this group). Be sure to include an ‘alerts’ section if there is anything significant that you want them to pay close attention to. You will essentially be ‘training’ them to look there first so they will be sure to see right away what you definitely want them to see.


Summary


Many individuals need access to status updates from our projects – especially the high priority highly visible projects. But not everyone wants or needs the level of detail that you give to those who are heavily involved on a daily or weekly basis. And to give them too much information will cause them to pay little to no attention to your regular ‘knowledge dump’ of everything important on the project – which is not what you want to happen. Be creative in how you communicate the essential information on the project and you may find that – as I described here – it is best to tailor it a little to different sectors of your project community to make sure that the information has its desired affect.

Does your organization handle large, complex technical projects? Do you have diversely skilled project teams assigned to those projects? How about overloaded project managers? Are they juggling several projects at once? This sounds like every organization I've managed projects in and every company that I've consulted for along the way. If this is your organization, too, then you likely need the best of the best in terms of a business analyst on each project being led and executed on for the project customers your organization is serving.


If you do need the “best of the best”, then what skills or characteristics are you looking for? What defines the best for your organization's project needs? While BAs are not project managers, the most successful BAs manage the entire business analysis effort. This means that the BA is proactive and dependency-aware. It also means they manage themselves well, the stay on track with respect to commitments and deadlines and can handle task delegation, decision making and issue management as needed on the project.


I've thought about the overall skill set and characteristics needed to pull this role off efficiently and productively and coupled it with my experience leading projects, working in combined project manager and business analyst roles I've come up with my list of ten characteristics of an awesome business analyst. As you are reading through these, please be thinking of your own personal experiences and comment with your additions to this list...


Great customer interface. The great business analyst is a critical liaison between the project manager and the technical team. This person is often the driving force behind the accurate, complete and detailed documentation of the final project requirements. Why? Because the organizational to tech cross-over ability and skills that many project managers will lack must be handled in this role. And they help the tech lead interpret those functional design ideas into technical design specifications for the design and development work on complex technical solutions.


Subject matter expert. The skilled business analyst is vital in his project team role as a subject matter expert. This helps him to work with the client to document accurate business processes that are then used to create detailed, complete, and accurate project requirements. The business analyst's technical knowledge coupled with his understanding of the design process and the likely end solution makes him an invaluable resource for the project manager the project team and the project client.


Good technical cross over. The very valuable business analyst has a diverse amount of technical knowledge. Not necessarily tech lead or developer knowledge, though that is a plus, but rather a very good technical acumen that gels with the project management-type organizational skills and knowledge he also likely possesses.


Can project manage it when needed. The indispensable business analyst can and often does act in the role of project manager both when the project manager may be tied up on another project and also when interfacing with the team and client and a decision needs to be made on the project's behalf and the project manager isn't currently available.


Critical attention to detail. Detailed oriented focus is needed by the business analyst on the project for a variety of reasons: to assist the project manager and fill in there as needed, to work closely with the customer sponsor and team and the project team to define and document requirements, and to help track and resolve issues throughout the engagement.


Skilled communicator. I've often said that communication is Job One for the project manager. However, communication skills are possibly the most important characteristic of the awesome business analyst if for no other reason than the vast responsibilities this position has on the project and with the team and customer. Miscommunication can lead to so many problems on the project and this role ends up interfacing with all stakeholders...making accurate and thorough communication necessary.


Facilitation skills. The business analyst is going to be required to facilitate many meetings and sessions during the project such as periodically leading the team meetings and formal project status meetings for the project manager and then requirements meetings with the customer as well as design sessions with the technical project team.


Experienced critical thinker. Business analysts are responsible for evaluating multiple options before helping a team settle on a solution. While discovering the problem to be solved, business analysts must listen to stakeholder needs but also critically consider those needs and ask probing questions until the real need is surfaced and understood. This is what makes critical thinking and evaluation skills important for the business analyst on the project.


Skilled with PM and organizational tools. The business analyst needs to have a good command of the use of various project management related tools such as project scheduling software, basic tools like Word, Excel and PowerPoint, and others that might be needed such as task management software, bug tracking software, risk management software, file management software, and even modeling tools like Visio, etc.


Conflict resolution. From time to time conflicts can arise. I'm not talking about fisticuffs...at least I hope not. But disagreements among technical team members or with members of the customer's staff can arise. The skilled BA will recognize this quickly and work with both sides to come to a mutual agreement. Patience is also a virtue...because any conflict resolution requires patience and understanding. And good listening skills.


Summary / call for input


The business analyst isn't necessarily the leader on the project, but his role may be the most diverse and sometimes the most critically necessary for project success. The project manager will serve as the overall communicator and decision maker on the project, but the business analyst will likely have an even closer customer facing role than the project manager...meaning this position may be the most valuable in helping ensure customer satisfaction and completeness and acceptance of project work performed by the project team.


How about our readers? If you're a business analyst, what do you think about this list? What would you add to or remove from this list? What are your top 3 or top 5 characteristics for a valuable business analyst? Some organizations – often smaller organizations – may only hire a project manager or business analyst to handle both roles. Have you worked with such an organization and did you find it to be successful?

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.