I’ve had this one come up twice in the last couple of weeks. What do you do if, even with all the resource allocations and assignments, all the planning and matching project demand to resource supply – what if there is still a lot of churn? You know, resources are still continually reassigned. Or worse, they flit from one task to another based on pressure from various quarters.
While this churn happens in many organizations, I’ve personally seen it many times in New Media companies. These are firms that create all the banner ads, quick videos, CD promotions, short videos, and other new advertising media. Typically, these engagements are like quick hit projects where items are designed and created in days. And a pool of Web developers or copy writers are working with multiple clients concurrently.
In these high-volume, quick-hit types of environments, we often see a malady we call “resource day-trading”. As the name implies, project or account managers are constantly trading resources to get their work prioritized. Like with stock day-trading, there are serious pitfalls, namely inefficient use of resources, lack of alignment, missed deadlines, and budget overruns.
So, how do you handle these high-churn environments? Set up regular resource planning meetings. We did this at one New Media client (the new media arm of one of the largest ad agencies in the US). We designed reports that showed utilization from the last 2 weeks, and allocations for the coming 2 weeks. These reports were produced on Friday. On Monday, the Account Managers (which are basically PMs) and Resource Managers met. They reviewed the reports, discussed the next week’s priorities, and re-allocated as necessary.
By re-allocating as a group on a regular basis, they almost totally eliminated the ad-hoc reallocation that caused so much trouble. And their productivity (as measured by revenue per employee) improved by 300%!
I have had several clients successfully implement this best practice. It greatly improves communication and makes sure everyone is on the same page. This is one meeting that is attended and is definitely not boring!
An oft-heard refrain in IT Project Management circles:
If the business would get their requirements right, we’d be able to deliver this project on-time!”
How many project delays have come from shifting scope and requirements? More than a few, based on my experience. So how does one approach this problem?
Part of the answer lies in the question itself. It assumes that the business is responsible for imparting their requirements to IT in such as manner that IT can successfully deliver. Yet “the business” often knows little about the underlying technology, and thus has a hard time articulating their requirements in terms the technologists in IT will understand.
What is needed – and what works in successful project and IT departments – is a translator. We often think of the business analyst role fitting the bill perfectly. Their job, after all, is to understand the business issues and help determine the technical requirements that will fit the bill. The problem is, they are not driving the project – the project manager is.
There is another issue in this conundrum: sometimes the business customers of a project think they know what they want in technology terms, and try to input their requirements in that manner. Something like: “We need a new sales force automation system that is web-based, syncs with MS Outlook, and integrates with the finance system”.
Why? Perhaps they are trying to increase the efficiency of the sales force. Or, perhaps increasing their visibility into credit issues through finance. Or, they need better visibility into the sales pipeline.
My point here is simple: For a project to be successful, a clearly defined business target is required. This is a vision that sits above the requirements. Indeed, if specific requirements don’t help produce that vision, they may not belong in the scope of the project. It also helps to separate the critical items from the “nice to have” requirements.
Given a business target, the project needs a Project Manager that understands the target and can drive the team to deliver. Why the project manager? Because business is a fluid undertaking, and the requirements may indeed change – but the vision should not. The project manager needs to be able to collaborate with business stakeholders – on their terms – to help sort through the shifting landscape and determine if and when changes to the project are required.
I was once asked to manage a large payroll system enhancement project. Lots of detailed requirements, lots of good business reasons to upgrade, including changing tax regulations and international expansion. And over 100,000 people on the payroll. I asked the VP in charge: “Why me? You have plenty of qualified project managers in IT.” Her reply: “Because, at the end of the day, come hell or high water, I know you will make sure all of those employees get paid.”
Now that’s a business target.
In my “Maximizing IT Capacity” webinar the first poll asks “How much of your time do you log? Of the choices, “none” is the most common response, with “project time only” running a distant second. Yet when it comes to understanding resource issues, actual time is the most valuable information around. By analyzing the prior 12 months time records at PeopleSoft IT, we increased our project capacity 30%, and staved off drastic staff cuts during the Oracle battle.
Why is this information so valuable? Properly analyzed, it provides insight into 3 key areas.
Feedback to project planning
In a PMO, we tend to concern ourselves with resource allocation to projects. We also spend a lot of time estimating task effort and resource requirements. Indeed, these estimates drive our project schedules, and ultimately the delivery dates promised to our customers.
So, how do we know if our planning is accurate? Most project managers rely on experience, and hope they’re close. But it’s the empirical date from time logs that reveals that the 40 hour task that completed on-time actually took 60. People worked overtime, or borrowed someone, to get the job done. And next time, we’ll estimate this task as a one-weeker again, but might not get so lucky.
Continue reading Do you log your time?
There seem to be a couple of immutable truths in the PMO world, especially in IT departments. First, there is always more work than can possibly be done. This usually surfaces in the form of an insatiable appetite for projects. Second, no matter how you prioritize the work, someone’s going to be unhappy – and they’ll try to make your life miserable by becoming the squeakiest wheel in the company.
The answer, as we PMO practitioners all know, is to elevate the prioritization decisions up to the company executives. This usually means some sort of cross-functional steering committee or other governing body. It’s great theory, with one major flaw. Those execs don’t readily participate. I can’t count the number of poorly attended steering committee meetings I’ve run across. The execs either don’t show or send a lower ranking delegate not empowered to make decisions. Which leaves the steering committee pretty powerless, and results in the CIO once again making the decisions. And once again taking the heat.
So, how do you get these all-too-busy executives to pay attention and take responsibility for prioritization? The best process I’ve found is what I call “shock therapy for the executive team”, and it involves three steps: Presentation, Argument, and Decision Time.
Continue reading Project Prioritization: Getting Execs to Pay Attention
OK – this week I am going to delve into a rather controversial subject in the PMO community.
There is a raging debate occurring on the PMO board at PMI about the relationship between Project Managers and PMOs. It was all started by a gentleman who posited that most PMs hate PMOs, and asking for input as to why. This has lead to two camps on the subject.
In the first camp are those who agree that PMs hate PMOs. Their line of argument is that PMOs and the methodologies they impose are seen as a threat to the creativity of PMs, who would rather follow their own tried and true processes than conform to a rigid methodology. They are also afraid of exposing the “meta-data”, mostly related to performance of their projects. The PMs do not like the added administrative overhead, including signature gathering, regular status reporting, and the like imposed by the PMO. Finally, PMs do not appreciate the portfolio view of projects and would rather be left alone to manage their specific projects to success.
The other camp says this is pure nonsense – professional project managers are known for bringing good, sound project management processes and discipline to the table, and are therefore fully supportive of the work of the PMO, and readily comply with and enhance the work of the PMO. They also understand that good portfolio management is key to their own success. If their projects are low priority, lack sponsorship, etc, then their chances of success fall accordingly.
Naturally, yours truly has weighed in on this debate. I have found that which camp a project manager falls into can be heavily influenced by how the PMO is implemented. If the PMO adopts a rigid, one-size fits all SDLC methodology (see Common PMO Mistakes on this blog), project managers will have a difficult time succeeding. This kind of “police state” PMO almost always fails, with PM dissatisfaction being one of the primary reasons for failure.
On the other hand, a truly strategic PMO that implements a flexible, multi-tracked methodology, properly prioritizes project demand, and matches that to available capacity, becomes the project manager’s best ally. These PMOs also listen to input from their PMs to constantly improve the organization’s project management processes and culture. Finally, proper automation can go a long way toward relieving any additional administrative overhead, while increasing visibility and collaboration. In short, professional project managers feel they are an integral part of these successful PMOs, and that the PMOs are critical to their own success.
What’s your experience? Please feel free to weigh in on this debate! I’m sure we all have a great deal to learn about making PMOs more “PM friendly”.
Earlier this month, I had the privilege of attending and presenting to the inaugural PMO Symposium, presented by the PMO Special Interest Group (PMOSIG) of PMI. This turned out to be an extremely valuable event, with presentations that included some great academic research on PMOs, case studies from successful and challenging PMO situations, and some cutting edge theory. The latter category included my presentation on Comprehensive Resource Management, which played to a packed house and received rave reviews (at least at the bar later  I was also asked to sit on a presenter’s panel where four of us were peppered with great questions from the general audience.
Some highlights, at least from this attendee’s perspective.
Interesting Research:
Two researchers, Brian Hobbs and Jim Pennypacker, presented some interesting survey data on PMO’s in general. The highlights, from my point of view:
Best Practices:
Here’s a question I get asked with almost every PMO engagement – what are best practices for a PMO? Hobbs’ research indicates some interesting facts that back up my own anecdotal perceptions. First, there is no real agreement on what a PMO is, let alone what would be best practice. Let’s start with the meaning of the term. Is it a Project Management Office, a Program Management Office, or something entirely different? In my own practice, I’ve seen Project Support Office, Project Guidance Office, Project Center of Excellence and several others. Pennypacker uncovered some truly interesting names, including “Office of the Multi-Year Plan” and “Innovation and Planning”.
The mandates of these PMO’scover that gamut from managing single projects and programs to the Strategic Project Office (per Pennypacker), which can engage in Project Governance, Portfolio Management, and Resource Optimization.
One area of agreement was that there is a sub-set of services, yet to be defined, that are generally offered by PMO’s, depending on their mandate, and that it may be possible to create best practices around these services.
Industry segments and company size:Of real note, Hobbs’ research showed no correlation between the type and mandate of PMOs by vertical industry or company size. If there is a common thread, it is that PMOs are formed to solve specific problems, and their mandate stems from this. They are usually born from a specific pain point, such as poor project execution, resource overload, or poor portfolio visibility.
Where do Project Managers report?The research, and my own anecdotal evidence, both suggest there is no best practice around this. In Hobbs’ research, 50% of the PMOs surveyed have project managers reporting to them.
What correlates with success?Hobbs’ research suggests some correlation between perceived legitimacy of the PMO and a few key factors:
% of projects within the PMO’s mandate
% of project managers reporting to the PMO
Decision-making authority
Resources not matrixed
Supportive organizational culture
Project Management maturity
Number of important functions
So much for the interesting research.
Marketing the PMO:
Hugh Woodward presented some compelling information, based on research, on how to market a PMO.
First and foremost, he suggested using business terms instead of project management terms for measuring and promoting success. So, instead of touting how many projects are on-time and on-budget, talk about how a project is improving profitability, increasing market share, or otherwise improving business conditions in terms commonly used by your executives.
Hugh also notes the importance of linking projects to strategic objectives and value. This is a theme that was, of course, repeated throughout the conference.
Finally, be willing to change or kill projects as business conditions change. This is not a sign of failed project management, but rather shows the PMO’s flexibility and understanding of business. Projects do not exist for their own sake, and if there reason for existence changes, change or eliminate the project. Hugh gave an example of a project that was originally scheduled for 18 months, but ended up improving productivity so well, the life of the project was extended to 5 years to add scope and take the new techniques enterprise-wide. While this project may look years late, it was actually a huge success when measured in business terms – increased productivity!
Case Studies:
If there were common themes to this Symposium, it was found in the case studies and the information gleaned from all the networking with other attendees and presenters. The basic ideas were:
Successful PMOs focus on business results, not common project metrics
The Strategic PMO is becoming more common, and is often located outside of IT at an enterprise level. Even PMOs that started in IT are graduating to the Enterprise level. The common term here is now EPMO – Enterprise Project Management Office
Enterprises often have multiple PMOs, facilitated by the new EPMO
If there are causes for PMO death, it is typically that the PMO forgets its business purpose and becomes a bureaucracy. There is a related symptom I like to call “The Methodology Police”. Both of these symptoms alienate project managers and stakeholders alike.
Who should staff a PMO?
This question came up repeatedly, and consistently received the same answer, including by yours truly during the panel discussion. If we’re talking about a Strategic PMO (not a program specific PMO), the PMO head and key staff should be business leaders first, and project managers second. They are the link between corporate strategy and execution through projects, and need a solid understanding of the underlying business. The project management expertise needs to be there, but the business knowledge is critical to success.
One of then biggest obstacles to successful project delivery occurs right at the beginning of the lifecycle – deciding which projects to approve. You take in 20, 50, 100 project requests, and then it’s decision time! What do you do? If you’re like most IT departments, one of two scenarios occurs.
1 – The CIO looks the list over and decides, then takes the resulting flack from the stakeholders who were denied. And often his decision is based on the squeaky wheel principle – who will squawk the loudest if they don’t get their pet project?
2 – the CIO has had enough of being the fall guy, and either brings the list up to the executive staff meeting or forms a steering committee to make such decisions. This is a huge improvement, in that enterprise level decisions are now owned by the stakeholders. The problem is, most of these discussions degenerate into VP’s arguing over their pet projects.
What that steering committee really wants is information. What are the benefits of each project? How much will it cost? What are the risks if we do it? What are the risks if we don’t?
Continue reading Too many requests? Scorecard them!
I was speaking at a SIM (Society for Information Management) event the other night, when the question came up “What’s the most common mistake you see PMOs making?”. A great question, and a really great blog topic! At EffectiveIT Group, we encounter several PMOs a month, and so we have ample opportunity to see the good, the bad, and the ugly of PMOs.
So, here are my most commonly observed PMO mistakes. Feel free to add your own or comment on these!
-
PLAYING COP. If there is a common refrain to failed PMOs, this is it. The PMO becomes the “Methodology Police” and enforce an often ill-fitted SDLC rigorously. This leads to complaints from project managers at best, and open revolt and ignoring the methodology at worst. Rather than becoming an aid and guide to project managers, and creating consistency in PM practices, this PMO has become the PM’s worst enemy, loses visibility into the project portfolio, and leaves a bad taste in everyone’s mouth. Continue reading Top PMO Mistakes
|
|
