Process

Who Should Own the Resource Management Process?

ownership.jpg

One question I get asked a lot is: Who should own the resource management process in an organization? There are a number of considerations, and perhaps the first question to ask is: What should the role consist of?

First, let me clarify that ownership of the resource management function (maintaining resource data and assignments) is a different animal than owning the resource management process, and the answer may not be the same for both. For instance, often I see the PMO or some other central group or person own the process, while the functional resource managers perform the resource management function for their respective areas.

As for what ownership of the process means, it would typically include:

  • Defining the process and maturity path (e.g., who should submit assignment requests and enter assignments, when, how, and at what level)

  • Facilitating data building (master data such as cost centers, rate, working hours, and other resource attributes)

  • Monitoring adoption (examining data diagnostics to ensure the players are participating)

  • Gaining management buy-in (ensuring the management team at all levels is in agreement on the benefits and outcomes of the process)

  • Reporting on capacity and demand (making leadership aware of key areas of upcoming shortfall and gaps in staffing vs. the upcoming pipeline)

  • Recommending sourcing strategies (evaluating and proposing staff augmentation models to accommodate peaks in demand)

A PMO or RMO (Resource Management Office) is in the best position to conduct these organization-wide activities. In fact, a benchmark study I was involved in with Appleseed Partners on resource management and capacity planning practices showed that nearly 70% of organizations with mature resource management practices have a specific role or function defined for capacity planning and resource management. Only 26% of less mature organizations employ such a role.

With ownership of the role defined, the central function could help answer key high level business questions, such as:

  • How much resource time is unproductive (i.e., spent on lower value activities)?

  • What is it costing us to keep the lights on versus strategic projects and other work?

  • How much are we spending in each division and does this balance match our strategic intent?

  • How many FTEs do we need to support our current demand pipeline?

  • What is the expected benefit of our current pipeline of strategic projects? What are we willing to spend in order to achieve it with adequate staff?

  • What areas are we spending too much on that can be sacrificed?

  • What products, services, or software applications should be retired? Are we wasting valuable resources supporting them?

  • What skills are needed to excel in our future workload? Are we staffed adequately in our critical skill areas?

  • Which initiatives have already been funded? Are we able to meet committed business milestones and cycle times?

I would also suggest that performing the actual resource assignment and management function is best done by the individual resource managers. After all, they know their staff best and have the big picture of not only their staff’s current workload, but their upcoming workload. Resource managers and project managers should be in constant contact and work together to ensure proper staffing of work, based on priorities.

In all, having a dedicated and committed owner of the resource management process is a good way to ensure that resource planning, the #1 key driver of successful strategy execution, is properly addressed. And having resource managers participate in the process operationalizes it.


JB Manas - website photo.jpg

Jerry Manas is the bestselling author of The Resource Management and Capacity Planning Handbook, Napoleon on Project Management, and more. At PDWare, Jerry helps clients improve strategy execution through tools and processes that align people and work with organizational priorities. Connect with Jerry on Twitter and LinkedIn.

Why Simplification Leads to Greater Adoption

simplicity.jpg

Before the days of cell phones with great cameras, I went camera shopping in a specialty camera store. I was torn between a fancy Digital SLR camera that was powerful, but too large to always carry around, and a smaller, more portable automatic with good ratings. The manager said to me, "I always tell people that the best camera to own is the one you're going to use."

That lesson always stuck with me, and not just with cameras. It's especially applicable to software and process adoption. It's always best to start simple, and add ingredients as needed.

If the software configuration and/or your processes are as lean as can be, with only the functions that are absolutely necessary, they'll be much more likely to be readily adopted. Most resistance I see is either due to the "why" not being articulated, management not using the data to drive decisions, or overly complex processes and tools. 

Conquering complexity isn’t as difficult as it sounds.

  • Processes can be simplified by using basic checklists where appropriate, and avoiding redundant or unnecessary steps.

  • Tools can be simplified by first determining the output that’s critical for decision making and then configuring the input accordingly.

  • Focus on the goals and the problem being solved instead of all the magnificent possibilities you can think of.

  • Resist the urge to capture additional data "just in case."

  • Reports, too, should be simple and focused on key metrics. Read Edward Tufte’s The Visual Display of Quantitative Information to learn how to simplify reports and communication.

  • Communication can be simplified by making sure each message includes only one main point, augmented by up to three supporting points. 

I often refer to a brilliant statement from artist Hans Hoffman: "Simplicity is the art of removing the unnecessary so that the necessary may speak." This is true whether designing forms; communicating new policies or announcements; creating processes; or configuring software.  By opting for a lean configuration, engaging people in the creation of standards (you don't need to standardize everything), and focusing on only that which is necessary, you can "grease the wheels" for greater success. 

It's as simple as that.


JB Manas - website photo.jpg

Jerry Manas is the bestselling author of The Resource Management and Capacity Planning Handbook, Napoleon on Project Management, and more. At PDWare, Jerry helps clients improve strategy execution through tools and processes that align people and work with organizational priorities. Connect with Jerry on Twitter and LinkedIn.

When is Agile Not Agile? Common Mistakes to Avoid

Simpsons-sweatshop.jpg

As organizations strive to gain greater business agility, many are adopting Agile methodologies, not realizing that their implementation of it is anything but agile. In fact, it's often quite the opposite, turning the original set of guiding Agile principles on its head.

Bestselling authors Lindsay McGregor and Neel Doshi wrote an insightful article in HBR titled "Why Agile Goes Awry---And How To Fix It" that makes this very claim.

"In the spirit of becoming more adaptive," they say, "organizations have rushed to implement Agile software development. But many have done so in a way that actually makes them less agile." Not only that, it makes them less motivating.

The article goes on to contrast the original four guiding principles of Agile with the common practices that seem in direct opposition.

Regarding the principle of "Individuals and interactions over processes and tools," many organizations have let their Agile process become so rigid that people feel handcuffed by it and aren't allowed to question it. According to the article, developers and engineers have reporting feeling like “short order cooks.” Not surprisingly, I’ve heard this very term used myself in some Agile organizations.

And despite the mantra of "Working software over comprehensive documentation," some teams spend significant time documenting detailed user stories to the detriment of the true Agile mission of getting small experiments done in a collaborative manner.

Speaking of collaboration, the core Agile philosophy of "Customer collaboration over contract negotiation" goes out the window when the process involves work being passed like a baton from product managers to designers to engineers, with the customer nowhere in sight until release time.

Lastly, the principle of "Responding to change over following a plan" has become confused with "winging it" or "picking features that look interesting" as opposed to high value, strategically-important features that have been prioritized with the customer.

None of this is theoretical speculation. On the contrary, it’s sadly become common practice in many companies. Indeed, the authors based their findings on their study of engineering practices in 500 organizations, along with anecdotal evidence. 

The most striking finding of all was that these practices not only ignore core Agile principles, but they bring about the opposite result that Agile was intended to deliver. They demotivate people. As the authors put it, "Because they’re not allowed to experiment, manage their own work, and connect with customers, they feel little sense of play, potential, and purpose." 

It’s a sad, all-too-predictable, Dilbert-like situation. But all is not lost. The authors propose six changes to consider to better balance tactical and adaptive performance:

1. Software development should be a no-handoff, collaborative process.

2. The team’s unit of delivery should be minimally viable experiments. 

3. The team’s approach should be customer-centric.

4. Use timeboxes to focus experimentation and avoid waste.

5. The team should be organized to emphasize collaboration.

6. The team should constantly question their process.

For projects that benefit from an Agile approach (and not every project does), I couldn’t agree more. The authors expand on each in the article, so it's well worth a read.


JB Manas - website photo.jpg

Jerry Manas is the bestselling author of The Resource Management and Capacity Planning Handbook, Napoleon on Project Management, and more. At PDWare, Jerry helps clients improve strategy execution through tools and processes that align people and work with organizational priorities. Connect with Jerry on Twitter and LinkedIn.

When It Comes to Resource Planning, Timing is Everything

Timing2.jpg

Brightline (a PMI-led coalition of leading global organizations dedicated to helping executives bridge the gaps between strategy and execution) released an excellent infographic, developed by the Technical Institute of Denmark, called "Timing is Money." 

The infographic looks at four dilemmas that represent the four dynamic tensions that relate to timing when implementing strategy, particularly:

  • The Horizon Dilemma (near horizon vs. distant future)

  • The Urgency Dilemma (implementing quickly vs. moving too fast for your organization)

  • The Process Dilemma (tightly defined strategy vs. business agility)

  • The Rhythm Dilemma (natural work rhythms vs. getting everyone in sync when needed) 

Having written a book on common leadership dilemmas (Managing the Gray Areas), this approach is near and dear to my heart. Not surprisingly, for each dilemma, the infographic offers practical solutions that balance both sides of the equation.

I was particularly pleased that, for the Rhythm Dilemma, the recommended solution was to "dedicate and mobilize the right resources" and embrace new leadership rhythms that allow for syncing the disparate rhythms across the organization. 

This, of course, requires effective resource planning, which itself ties back to the other three dilemmas. For instance, the Horizon Dilemma applies, because you need to strike a balance between short term named resource planning and longer term skills planning. 

Regarding the Urgency Dilemma, having a clear picture of demand vs. capacity will let you know if you're taxing the organization beyond its ability to immediately take on something new. It also gives you the data to make informed tradeoff decisions.

Lastly, the Process Dilemma, which aims to balance strategy and agility, requires that resource forecasts show all types of work (Agile and otherwise) and depict how effort is being consumed across the overall prioritized backlog of the organization. This, in effect, helps tie effort utilization back to strategy, while also allowing for the change that business agility necessitates. 

Check out the infographic. Not only does it serve as a compass for bridging strategy and execution, it also serves as an excellent foundation for resource planning.


JB Manas - website photo.jpg

Jerry Manas is the bestselling author of The Resource Management and Capacity Planning Handbook, Napoleon on Project Management, and more. At PDWare, Jerry helps clients improve strategy execution through tools and processes that align people and work with organizational priorities. Connect with Jerry on Twitter and LinkedIn.

Focus Matters on Agile Projects, Too: Oscillation versus Iteration

Oscillation.jpg

In my last post, I talked about the importance of focus. Nowhere is focus more needed than on Agile projects, where change is king. I particularly recall an excellent article by one of the Agile founders, Jim Highsmith, where he talked about Oscillation vs. Iteration

As Highsmith pointed out, with short iterations and close customer interaction, it can be tempting to switch gears more than once. In fact, in some Agile projects, the gears are switching constantly. The customer keeps changing their mind. Multiple customers chime in with different needs. An emerging business imperative forces a change in tactics. Or worst of all, you didn't quite understand the need to begin with (or it wasn't articulated well enough).

Genchi Genbutsu.jpg

This is where I always point out the need to be an "anthropologist." Using the Toyota's lean manufacturing principle of Genchi Genbutsu (go and see for yourself) or Honda's Sangen Shugi ("three actuals," representing the actual place, actual product, and actual situation), you shouldn't just assume that what a customer asks for is what they need or want. Go and see for yourself what the situation is. At the very least, you'll have a better understanding of what they're asking for.

Likewise, just because you have an iterative, Agile project doesn't mean you shouldn't have design guidelines or requirements, or even an understanding of scope. Agile doesn't mean no planning or scope. It simply fixes the time and cost, and estimates the features and scope (as opposed to Waterfall, which does the opposite, estimating time and cost to deliver a fixed scope of work). With Agile, you're estimating what can and should be delivered to meet a certain objective, both in terms of defined iterations and for the ultimate project (typically a targeted release).

But back to our oscillation discussion, Highsmith cautions that it's not always easy to tell when you're oscillating vs. iterating. For instance, if government regulations keep changing or there are legitimate learnings that dictate a new course, then it's a normal part of Agile iteration.

In any case, the point is to be aware of when you may be oscillating, and if so, take corrective action before it gets out of hand.  And to avoid unnecessary oscillation to begin with, be sure to gain an understanding of the goals and objectives of your initiative (seeing the situation for yourself where possible).


JB Manas - website photo.jpg

Jerry Manas is the bestselling author of The Resource Management and Capacity Planning Handbook, Napoleon on Project Management, and more. At PDWare, Jerry helps clients improve strategy execution through tools and processes that align people and work with organizational priorities. Connect with Jerry on Twitter and LinkedIn 

Process and Productivity: Finding the Right Balance

PeopleVsProcess.jpg

Many organizations struggle with how much process to put into place versus "letting people do their thing." There are a number of perspectives to consider.

Quality legend W. Edwards Deming said, “If you can’t describe what you are doing as a process, you don’t know what you are doing.” My wife used to manage Deming's events, so I had the pleasure of meeting him a number of times and took a tour of his TQM principles in action on the USS John F. Kennedy. A consistent theme of his is that people don't fail, systems do.

Before improving a process, you have to have a defined process to begin with. Thus, key business functions need to be defined in terms of functional processes along with inputs and outputs of each. Then improvements can be made, either using Deming's "Plan-Do-Check-Act" method, Six Sigma, or other process improvement approaches.

But where do we draw the line between having defined and measured processes and creating an environment where people can flourish in an empowered fashion? After all, as highlighted in this Fast Company article on 5 Ways Process is Killing Your Productivity, managers can take it a bit too far, for example:

  • Damaging trust and bogging down progress with approval steps
  • Focusing on process over people
  • Excessive meetings (especially recurring ones) to "keep things on track"
  • Empty jargon-filled slogans and mission statements
  • Micromanaging and filtering new idea

One way to help ensure the right level of process and standardization is to engage people in creating it. Even the late Peter Scholtes, author of The Team Building Handbook and standardization proponent advised, "By involving people in the standardization of work, we can remove some of the oppressiveness of it. People are less likely to balk at standards they have devised." He went on to say, "We need not standardize everything."

As for process vs. productivity, Fons Trompenaars, my favorite author on cross-cultural communication (his book, "Did the Pedestrian Die" is a landmark achievement in that area), advises taking a "through/through" approach when trying to balance two seemingly opposite agendas. Instead of focusing on one or the other, think how you can improve productivity "through" process improvements, and how you can improve processes "through" a greater focus on productivity. it's not "either/or" and it's not even "and/and." It's "through/through."

In other words, always consider the people perspective when defining processes, and find ways to improve processes to boost productivity and reduce barriers.  For more on this, I expand on this and other common leadership dilemmas in my book, Managing the Grey Areas.

Meanwhile, whether you're instituting processes for resource management, project management, portfolio management, or anything, for that matter, consider the following points:

  • Before you improve a process, you need to define one
  • Keep it simple, and consider the people aspect
  • Engage people in defining the process and identifying two or three key measures of success
  • Use checklists instead of approvals where possible
  • When balancing two seemingly opposite perspectives (e.g., process vs. productivity), try a "through/through" approach to incorporate both perspectives
  • Once a process is defined, use Plan-Do-Check-Act or Six Sigma's DMAIC model to improve specific areas as needed

Author Subhir Chowdhhury summed it up nicely when he said, "Quality combines people power and process power."


JB Manas - website photo.jpg

Jerry Manas is the bestselling author of The Resource Management and Capacity Planning Handbook, Napoleon on Project Management, and more. At PDWare, Jerry helps clients improve strategy execution through tools and processes that align people and work with organizational priorities. Connect with Jerry on Twitter and LinkedIn