Strategic Planning as C-Suite Taylorism

I’ve been reading Henry Mintzberg’s The Rise and Fall of Strategic Planning of late.  It’s been a bit of a slog, primarily because I’ve been trying to read it on flights (which puts me to sleep) or at my daughter’s roller derby practice (which causes the other parents to mock me mercilessly*).

There’s an interesting thought presented very early in the book that has caused me to reflect a fair bit as I’ve been delivering presentations on strategic planning over the last couple of weeks.  The basic concept is that strategic planning is really an example of Taylorism as applied to the C-Suite.

A quick sojourn into the world of Taylorism…..otherwise known as Scientific Management: this is the concept that all work can be broken down into a series of manual steps.  This work is performed by the workers at the rubber-meets-the-road tier of the organization.  The workers are then watched by the supervisors, whose job it is to ensure the workers follow the agreed upon procedures.  The supervisors then implement the procedures defined by the manager class who by dint of their intellect and college education are qualified to develop the procedures that trickle down.  The entire thing these days and in some sectors smacks somewhat of the Eloi – Morlock dynamic, but in all fairness brings a fascinating perspective to the operating theories underpinning many modern organizations.  In fact, I might propose that most organizations I’ve worked with ostensibly reject the concept of Taylorism while simultaneously building the structure to support it.

Anyways, in a net-centric, information worker type organization, an alternative model has arisen – that of the empowered worker understanding the primary problem to be solved and then working independently or as part of the self directed group to push the goals of the organization.  (See posts here and here…..and this post on Yammer’s role in enterprise project management.)

The  book points out though that attempts to processize the strategic planning, well, process, have repeated the same structure, but this time pushed it upwards into the C-Suite and removed much of the art of strategic planning by replacing it with a mechanism to review goals from last year, adjust and issue a new plan for this year.

Attempts to implement strategic planning processes have removed some of the artistry of planning, and replaced it with a rote set of processes that must be followed at a specific cadence.  We see that with the emerging prominence of two distinct project portfolios:

Reactive Portfolio Proactive Portfolio
  1. Collect the list of requests for the next annual plan.
  2. Prioritize these requests.
  3. Perform constrained optimization.
  4. Release to execution.
  1. Define the long term goals and investment areas for the organization.
  2. Decompose the goals to develop a project portfolio leveraging the principles of enterprise architecture.
  3. Prioritize the project portfolio.
  4. Perform constrained optimization.
  5. Release to execution.

In the first portfolio, the reactive one, we simply have to collect all of the requests from the organization, run them through an analytical hierarchy that was defined per some other set of formal processes, and we have a portfolio.  In the second portfolio, the proactive one, we swap out the sensing mechanism of order taking with one that is a bit more proactive, i.e. mapping fundamental strategic change to the scope of the projects in the annual plan.  Regardless of which portfolio you support, the general premise however is that if we follow these two approaches to the letter, we will have success in our strategic planning.

So the question now becomes, if Taylorism has been widely rejected in many information worker organizations, and if strategic planning is merely Taylorism writ large, then what would a rejection of Taylorist strategic planning processes look like?  Well, it might look a lot like decentralized program or asset based planning.  Specifically, funds would be allocated flexibly to the asset based off a prioritization matrix that identifies the importance of the asset and how well the asset is meeting its target performance.  (See this post on the program as a benefits management framework.)

Each asset would then be owned by a specific individual, a program manager who would be responsible for allocating funds to best guarantee the asset meets the needs of the organization.  The prerequisite for this to work?  A clear definition of where the organization would like to go – and how each asset supports that definition.  Note how this structure meets a clear need, that of transferring ownership of the project and the defined initiatives to the teams responsible for doing the work.

That is what a strategic planning function would look like if we designed it in a manner consistent with the principles of modern information worker process design.


*…despite my protestations that reading a book like that at roller derby practice reflects the duality of man…you know, the Jungian thing).

Strategic Planning as C-Suite Taylorism

[Utilities] PMO Strategies & Capital Investment Governance Webinar

Excited to announce this upcoming utilities-focused webinar on March 12 (2:00-3:00 EST) with UMT and Frank LaRocca, Director of Business Improvement Services for ConEdison.

  • Learn from ConEd’s experiences and insights on building governance and an enterprise PMO for multi-billion dollar capital investment portfolios.
  • Hear about the latest innovations in agile operating models that deliver and exceed historical performance across electric, gas and steam operations.

For more information, to register and/or to see the case study, please click here.

[Utilities] PMO Strategies & Capital Investment Governance Webinar

Applying Enterprise Architecture to an EPMO Process Framework

Thinking a bit more about last week’s post on scoping the EPMO.  In that post, I asserted that there are certain “stock” capabilities that an organization requires to execute projects.  Some of those capabilities should be best owned by the EPMO, some by the various PMOs supported by the EPMO, and some jointly owned by both.


One thing I left out of that post was a suggested framework for how to determine where a specific capability might actually fall, i.e. should it be considered a centralized capability or a decentralized capability?  As I was thinking about this, I realized that the framework proposed by Jeanne Ross, Peter Weill & David Robertson in their page turning EA book, Enterprise Architecture as Strategy, could be brought to bear on the discussion.

As I’ve mentioned before on this blog, they suggest reviewing architecture from the perspective of unified process and/or data.  Every capability should be reviewed by asking two simple questions:

  1. Do we need to centralize and standardize the process that each of the PMOs and EPMO follow?
  2. Do we need to centralize the data that each of the PMOs and EPMO generate and/or use?

Simply put, you can take each of the capabilities in the above chart and map it on the following 2 X 2:


After going through that exercise, that should give you a decent foundation upon which to allocate ownership of the various capabilities inherent in a PM system.

Applying Enterprise Architecture to an EPMO Process Framework

Deliverable Dashboards with SharePoint Workflow

A common request in project management is to be able to create a dashboard for each project that shows the status of specific defined deliverables that must be created.  For example, the project manager must be able to see that a SOW or proposal has been posted to the site.  The project manager must also post a status report to the project each week – or get flagged as being out of compliance.


In prior versions of SharePoint, this was typically performed through the use of custom code.  For this post, I decided to sit down and see if it could be done with a little SharePoint Designer workflow.  Turns out it wasn’t hard at all.

To create this solution, we’ll need:

  1. A custom SharePoint list for the dashboard
  2. A document library
  3. A couple custom content types
  4. One list workflow on the document library
  5. One site workflow on the dashboard list

Dashboard List

This is a simple list with a couple of fields:


Note that Status is a drop down with Red, Yellow, and Green as the available options.  (Red is the default).

I modified this list to add conditional formatting using SharePoint Designer 2010 as in this blog post.  It looks like SharePoint conditional formatting is being deprecated in 2013, so this is a bit of a hack where I had to install SPD2010 to get this to work.  I’d trust smarter folks than I to figure out a better way of sprucing up the dashboard – i.e. adding icons or leveraging some other method to create the conditional formatting.  For today’s post, this will do the job.


Add list items to your list for each deliverable you will be tracking.  I used the same names as the content type in the document library to facilitate the workflow finding the correct item to update.

Document Library

For the document library, I added a couple of content types and an Approved field.


Dashboard Update Workflow

I then created a simple workflow on the document library.  This is set to trigger whenever a document is created or modified.


Adding some additional detail to the picture above:

  1. Line 1 picks up the UID (as a string) of the dashboard item corresponding to the content type of the document in the document library.  This allows some minimal error handling by skipping the items that will throw an error if it can’t find a dashboard entry corresponding to the document content type.
  2. Line 3 establishes the URL of the document in order to populate that in the document dashboard – so the user can click directly from the dashboard to the document.
  3. The if….then clauses flag the dashboard item as green or yellow depending on if the document has actually been approved.

Here’s a shot of the step that updates the dashboard item.  (This is for approved documents.  The other one will flag the item as yellow.)  Note I’m copying the Last Modified date into the dashboard Updated field.


That will update our dashboard list per our requirements.  One more quick item, and we’re good.

Status Report Monitoring Workflow

For the final step, I want to add a bit of logic to flag the status update column yellow if no status update has been posted in the last week.  To do this, I’ll create a site workflow that will wake up every 24 hours, check to see if a new status update has been posted, and flag the item as yellow if it’s been a week since the last update.

That workflow looks like this (if anyone can suggest a better way to present SPD workflow in a blog post that’s not too tedious, let me know.)


More detail:

  1. Line 1 is pickup up the GUID for the status report item in the dashboard list.
  2. I’m basically picking up the Updated date, adding 7 days, then comparing it to today’s date to determine if the item must be shifted from green to yellow.

And there you have it…one compliance dashboard.  If anyone has suggestions on how to clean up the look and feel of the dashboard itself, feel free to post in the comments section.



Deliverable Dashboards with SharePoint Workflow

The Microsoft Platform and the Evolution of a PMIS

Is a doorway a frame around empty space?  Or is it the space that is surrounded by a frame?  When selecting a PMIS platform, the same question should be asked.  Is a PMIS a series of solutions within an empty white space?  Or is the PMIS the empty white space populated throughout with a series of solutions?

For those of you not familiar with the PMIS term, it’s a standard industry name for a Project Management Information System – or any system within your organization that is used to track project data.  The PMIS could be a filing cabinet.  It could be a series of notebooks kept by engineers.  It could be an incredibly complex series of IT tools integrated through a data warehouse and a service bus.

Regardless of the technology underpinning it, the PMIS needs to serve specific functions, whether that is project tracking, portfolio analysis, resource management, risk management, or any one of the other key knowledge areas or processes defined in the PMI literature.

The particular form of a PMIS that’s supported by IT tools is part of our stock and trade.  As we see it, this PMIS evolves in different forms.

In some companies, there is no formalized PMIS.  In these organizations, there’s typically not a lot of formal project management processes, and most things are tracked in Excel – perhaps with some financial management in a specific tool such as Oracle or PeopleSoft.

In other organizations, there are a wide range of point solutions.  This is often associated with (but not exclusively with) large organizations where the project management function has been broken out in to a wide variety of distinct offices.  In these organization, there may be an enterprise architecture office, a risk management office, an office that deals with projects just being developed, an office that deals with projects that are more advanced, a reporting office…you get the picture.

The Microsoft platform has a different value proposition in each of those scenarios.  Note here that when I talk about the “Microsoft Platform.” I’m not simply talking about Microsoft Project Server – but rather the full panoply of Microsoft solutions: SharePoint, Project Server, Yammer, Power BI, SQL, etc.

For the first kind of organization, the one where there’re not a lot of formal tools in place, the Microsoft platform provides an excellent foundation to build upon.  Build your collaboration and document management workflows in SharePoint.  Build project scheduling practices and resource management in Project Server.  Enhance knowledge capture through Yammer.  Report on all of this in the Microsoft BI suite.

The challenge here is that Microsoft in presenting itself as a platform becomes a victim of trying to be all things to all people.   Microsoft is great for basic scheduling – but if you are attempting to model critical chain scheduling, you’ll need an add in.  If you’re attempting to do Earned Schedule analysis, you’ll need an add-in.  If you’re looking to manage large industry-specific design documents, you could do it in SharePoint, but you’ll likely be looking at another solution that’s more tailored to the specific needs of the industry.

For the second type of organization, the kind that already has a lot of solutions already in place, we find value in evaluating them and bringing them into the SharePoint fold.  Retire the ones that are superfluous.  Integrate the ones that aren’t.  At the end of the day, the Microsoft platform provides a single integrated user interface from which to navigate to those tools – and a data structure to enable integrated reporting.

At the end of the day, selecting a PMIS platform is less about point solutions and more about filling the white space within the organization’s project delivery organization.

The Microsoft Platform and the Evolution of a PMIS

In Portfolio Management, the Best Defense is a Good Offense

People often ask me what I do in my role at UMT.  That’s a great question.  The answer is really quite simple:

  • I help organizations define what they want to accomplish through their project portfolio.
  • I help organizations align the projects they’re working on with what they hope to accomplish.

Needless to say, there’s a lot of work to be done on each of those bullet items – whether it be identifying operational constraints or eliminating waste and mitigating risk in the project delivery process.  In this role, I work with organizations at various levels of portfolio management maturity.  Some organizations are just focusing on getting an idea of what projects they’re working on and what constraints apply to those projects.  Other organizations are grappling with the pressing issue of trying to figure out how to prioritize those projects.  Still other organizations are grappling with the issue of whether or not the list of potential projects is even the right list to be considering.

When companies first begin to tackle portfolio management, they often start from the perspective of aligning their current planning processes.  Every year, projects are proposed by specific individuals within the organization.  These projects are added to a central repository of project work, and then rated on how well they align with specific strategic imperatives of the organization.

Sounds good right?  There’s nothing inherently wrong with this approach – but it invariably leads to questions such as “How does this project actually align with strategy?” or “How do we track benefits for this project?”  When each project is proposed as a stand alone entity – and treated as such, it becomes difficult to answer these questions.  This collection of projects doesn’t comprise a comprehensive strategic approach – but instead simply a collection of individual answers as to what is most important to the organization from the individual’s perspective.

It reminds me of the Mongol term for rice – buda.  It’s used to describe something as irreparably broken, that is now a collection of parts that cannot work together.  If a truck engine is buda, then it is like a handful of dry, white rice.  No matter how much you squeeze it, you’ll always have a collection of separate grains.  It doesn’t matter how many hours that truck will spend in the garage, those engine parts will never cohere to form a functioning engine again.  A project portfolio built from the bottom up is no different.

The issue is that the organization is playing defense and being reactive by fielding the project requests.  The trick to successful portfolio management is to go to the offense.  Instead of starting with the projects, and attempting to align them to the strategy – start with the architecture of the organization, and then forecast your projects to support that.

Start with the business plan for the next 18 months – or whatever time frame makes sense given the volatility of your industry.  Decompose that into business capabilities, services, and the assets that support those services.  This gives you a framework to understand what the organization needs to be doing at a tactical level.  As the organization changes, use this framework to identify the projects that we should be working on.

The white space around the strategic changes is filled with the BAU work that must be done.  This, too, can be proactive.  Each asset added to the enterprise environment requires constant updates, upgrades and maintenance.  Budget for that.  Understand that in the case of an IT application or a production facility, each year we will be making updates and modifications.  In a couple years, it will be retired and replaced.

There’s still room in this framework for the pop up individual requests.  After all, those capture the oversights – the gaps between the strategic plan and reality.  However, once the portfolio planning becomes more proactive, there will be a lot less of these unplanned requests – as chances are they were just manifesting as examples where individuals had perceived a gap between the current and the desired future organizational state.

When you start from this architectural framework, you end up with a proactive, forward looking portfolio of projects queued up for the foreseeable future.  You’re not playing defense and fielding individual requests.  You’re providing a benefits measurement and strategic context for each of those individual initiatives.

At the end, the success of a portfolio management lies not with a defensive mechanism of saying no to the low value projects, but with an offensive mechanism that relies on the quality of what I call the sensing mechanism – that piece of the puzzle that contains the processes that comprehensively defines the gaps between the current and desired future state.

In Portfolio Management, the Best Defense is a Good Offense

Why Are We Talking Yammer at a Project Server Conference?

Man, that’s a great question.  I’m glad you asked.

Of course, there’s the technical reason.  Yammer is owned by Microsoft and falls under that same collaboration SharePoint umbrella Borg thing that Project Server also falls under.

Then there’re the organizational reasons….a couple of the folks from the Microsoft Project team that we all knew and, well, if not loved, at least generally enjoyed working with, jumped ship a year or two ago and moved over to the Yammer side of things.

And then there’s the fact that Yammer and Project Server really represent two sides of the same coin.  At the end of the day, the entire SharePointYammerProjectServerCollab story is really one of enabling teams, whether they be project teams, technical teams, management teams, or any other kind of team.  It’s a story of breaking down each individual’s personal identity and reforming it as part of a larger group with a common goal.  That larger group may be the project, the PMO, or the entire organization.  At some point, the membership and very identity of that group pivots around a central, common idea, or goal.

Yammer, to be specific, and collaboration tools in general, help groups determine their own path to achieve that goal.  It facilitates self-organization of the group to best achieve goals.  And that, by the way, is how you know you’re using Yammer correctly – if you’re using it (to paraphrase Michael Schrage) to create a shared experience and not to share experiences.  The latter means you’re just using Yammer as an internal corporate Facebook to share pictures from last quarter’s sales meeting.

Project Server, and project management tools, on the other hand are a much less tolerant of ambiguity.  Project Server is the X to Yammer’s Y.  Project Server is all about the metrics.  Project Server allows us to define our goal, and then to assess whether or not we’re going to achieve it.  Project Server brings the hard calculations missing in a pure collaborative space.

In a broader sense then, Project Server allows us to identify challenges in achieving our goals.  At the project level, that may mean finishing on schedule.  At the enterprise level, that may mean that we’re not focusing on the work we should be.  Either way, these metrics help quantify the challenges to achieving our shared goal.  These metrics create the shared problem space.  Collaborative tools help us develop solutions to these problems.  Both approaches are required to reach the finish line.

What’s interesting is the fundamental difference in approach from both tools.  Whereas Yammer assumes the existence of intrinsic motivation on behalf of the participants, as a more metrics driven tool, usage of Project Server is usually driven by extrinsic motivation.  It’s the difference between saying, “I want to work with this guy to achieve my goals,” and “I need to get my data in so the reports look right when they go to the boss.”

If you look at the work of the organization as occurring along a continuum, there is a certain structure that must be followed.  Within that structure, there’s a certain grey area that can be exploited to make the organization nimble and responsive.  This is a complementary arrangement that delineates the space in which Project Server and Yammer play.

Why Are We Talking Yammer at a Project Server Conference?

Clear Goals and Fuzzy Roles

Fresh out of college, shortly after starting a new job, I remember my old boss sitting me down and giving me some advice.  “To succeed in this job,” he said, “You’ll need a high tolerance for ambiguity.”  That’s a theme that keeps recurring of late as I have been preparing for a couple presentations at the upcoming Project Conference.  Specifically, it’s a theme I’ve been revisiting in preparation for co-presenting a talk on how the PMO can both be collaborative and help an organization become more collaborative.

As part of that preparation, I’ve been reading Chris Argyris’ Flawed Advice and the Management Trap: How Managers Can Know When They’re Getting Good Advice and When They’re Not.  I also picked up a used copy of Suresh Srivastva’s Executive Integrity: The Search for High Human Values in Organizational Life.  Specifically, when reading an essay in there by Steven Kerr on Integrity in Effective Leadership, a couple things clicked with some of the discussions I had at the PMO Symposium in San Diego last November.

One of the cornerstones of having integrity as a leader, Kerr writes, is to remove ambiguity around the organizational goals.  Everyone should understand what the organization wishes to achieve, and how it arrived at those decisions.  According to him, leaders should “clarify organizational values and priorities and individual rights and obligations.”  (He also writes about maintaining integrity between stated goals and performed actions – but that’s a different discussion).

So in this sense, clarity and definitions are good.  Argyris brings up an example of where clarity can actually be detrimental.  His book talks about the difference between internal and external motivation.  Internal motivation is driven by a need to achieve goals.  External motivation is driven from a desire to look good – which in the corporate world, often means hitting our target metrics.  The problem with role definitions, he writes, is that when they are overly precise, they remove the element of internal motivation from our work.  They end up reducing our jobs to specific processes that must be followed.  Inevitably, that replaces internal motivation with external motivation.

In reconciling those statements then, we can derive some guidance on how to construct a high performing organization.  We clarify what we are hoping to achieve.  We maintain ambiguity about how to get there and about how people will interact to achieve this.  We clarify the “what”  while deferring the “how” to the team.  This is how collaborative cultures are born.

Note however that this does not constitute a wholehearted endorsement of vague position descriptions.  That sort of thing would never fly in a team that is going through the “storming” stage of team development, i.e. when each individual is coming from a different organizational or departmental culture.  Vague position descriptions only work in a team where everyone agrees on what they’re trying to accomplish – and when the desire to achieve the goal (internal motivation) supersedes the petty disagreements on how to achieve it.

So what’s the PMO’s role in all of this?  That speaks to the changing role of the PMO.  Increasingly, I see discussions of the PMO as a cultural change agent.  The PMO’s role is one of communication – both vertically and horizontally within the organization.  The PMO’s job is to maintain the prioritization structure for new work – and to communicate how projects align with that prioritization structure.  The PMO then is chartered with ensuring consistency and clarity between the stated goals of the organization and the actual work of the organization.  This is achieved through project selection mechanisms, through strategic scorecards, and through simple things such as maintaining a top ten list of all projects within the organization.

The PMO often provides both the catalyst to define organizational clarity as well as the vehicle to communicate that clarity through clear project selection and prioritization mechanism.  That is one of the building blocks to achieve a high performing team – and by definition, a collaborative culture.

Clear Goals and Fuzzy Roles

Operating Models and Portfolio Segmentation

Catching up on some of the comments that have been left on a couple of blog posts recently:

Prasanna Advi wrote:

“I think the key is ‘how’ do you decide what those top 10 (projects in the organization) are, and make every Business Unit agree to the same critera. Especially, in the intersection of Business and IT. I think you should write about the “How” to achieve strategic criterion alignment across a multi-busines unit organization!!” on Does Your Project Matter?

And Josh Milsapps wrote:

“I am very interested in your upcoming post that ties in elements from what I assume is EA as Strategy by Ross and company,” on PMO Symposium 2013 Wrap Up: It’s a Translation Thing.

So there are a couple of concepts here that all appear interrelated.  The first one is portfolio segmentation.  The first step in portfolio management, writes Jeffrey Kaplan in Strategic IT Portfolio Management, is portfolio segmentation.  In this step, we take all of the projects and work authorized by the organization, throw it onto a clean table, and start to organize it by the logical decision making architecture required to optimize the work.  We may end up with a single portfolio.  More likely, we’ll end up with multiple portfolios.   The trick, Kaplan writes, is to ignore the current organizational structure and seek to discern the logical structure.

The second concept is the operating model, as depicted in Enterprise Architecture as Strategy (Ross, Weill, Robertson).  This was (and still is) a seminal book in defining organizational decision making.  The basic gist, as Josh Millsap discusses in his Webinar here, is that organizations tend to follow one of four operating models based on requirements to integrate and standardize business process across various business units.  (Standardize = follow the same process.  Integrate = different processes but resulting data must be married, i.e. different business units from the same company serving the same customer.)

The four models are defined here, and I’d recommend reading the book and/or the Webinar for more information as I won’t do it justice.

  • Coordination
  • Unification
  • Diversification
  • Replication

Now, how do we combine these two ideas?  The operating model provides the fundamental skeleton of the portfolio segmentation.  Depending on how we define our model, we will need to segment our portfolios to support it.  If we have a Unification model, then we would essentially have a single portfolio shared across BUs – or several portfolios by process, but also shared by BU.  If we adhere to a Diversification model, we would then have multiple portfolios spread within each of the BUs.

The trick is, however, and going to Prasanna’s question, anytime we split portfolios into multiple segments, we need to retain an uber-portfolio of some sort, the kind described in Kaplan and Norton’s Execution Premium.  This uber-portfolio, or STRATEX budget, or ePMO, or whatever we call it, exists to fill in the gaps between the portfolios.  This is where the big initiatives that change the organization and that must be implemented across each of the portfolios (note, not BUs) reside.  For example, implementing or standardizing on a new operating model would reside in this uber-portfolio.

Admittedly, that leaves us with a bit of a grey line as to whether or not smaller initiatives in the sub-portfolios that support the strategic design of the company should be part of the ePMO domain or relegated to the subportfolios – and I am sure there are different answers to that question.

Hence, we can always look to find the top ten list of impactful projects and programs in the uber-portfolio.  By definition, that’s where they reside.  I can also perhaps find a top ten list of impactful projects and programs in the sub-portfolios.  Again, by definition, they won’t be as much of a priority as my ePMO projects.

Operating Models and Portfolio Segmentation