EPMO for a Smaller Company

In Waterfall we might need something else, but in Agile, what do we want from an Enterprise Project Management Office (EPMO)?  If we have a relatively small company (total employees near 1,000, innovation group near 100).  (Obviously, if the company were 300,000 people, it would be a different game.)

Let me discuss this in 7 sections, as follows:

• Premises
• Goals
• Two types of work
• EPMO’s role
• Information to provide
• Actions
• Concluding comments

1. Premises

In Agile, keep ‘management’ light, and an EPMO to many people does not sound light.

In the Scrum community, we are trying to move away from ‘projects’ and more toward teams and releases and products.  So, we think “Team x is working on product Y and expects the next release Z to be coming out in another 5 weeks.” This way of thinking typically has several implications:

• We think of customers and business value first.
• We want to release more frequently.
• The old ideas of ‘project success’ are meaningless.  (See below.)
• We expect almost all products to have a continuing series of releases.
• We look to one Team (or one scaled group) to deliver the releases for one product.  It is a real team, with a real mission, and hence, highly motivated.  And, because of that, more successful.

Again, there is a sense that ‘project success’ (as we used to think of it) is meaningless.  Changing scope – so what?  Moving deadlines (as long as we are getting quicker releases) — so what?  Conformance to an original schedule per se — so what?  The only thing that matters is business success: and that happens via releases of ‘product’ to customers.  And the people that are clearly responsible for delivering a release are formed into a Team (or a scaled group of Teams).

Another key premise: for a variety of reasons, we want the Scrum teams to be self-organizing, self-managing and self-directing.  This does not mean they operate totally in isolation, but the degree of ‘day to day’ management is much lighter.  They are expected to manage themselves.  Still, the Exec Team needs some oversight, and a simple EPMO implementation might enable the ET to provide that.

2. Goals

What are we trying to accomplish through an EPMO?

The main thing is that the ET (Executive Team) knows the different efforts underway, and is able to re-evaluate them and help.  By re-evaluate we mean they can stop one or maybe add something to another effort (if appropriate).  If an effort (team) is in trouble, then the ET could look into fixing the key problem or problems (in Scrum, we call these impediments).

(Background: In a smaller company the ET is the CEO and the other key executives, who might meet roughly weekly. Let’s assume they are 10- 12 people.)

Now, imagine you have 5 Scrum teams working.  Clearly the amount of reporting to the ET is relatively light.

So, the ET needs barely enough up-to-date information to know about and act on things like the following:

1. Identify whether the initiative (team) is going well, fairly well or not so well.
2. Review the relative expected benefits, costs and timelines of each release, as of today. (We expect them to change.)
3. Identify and perhaps address any of the 5 top impediments. (The ET may or may not decide to help with these, for a variety of reasons.)
4. Accept the timeline for the next release or two and whether that is sooner or later than previously stated.
5. Review and address any major adjustments in the scope of the release(s).  (Minor changes are outside the interest of the ET.)
6. Review and address any other major concerns (eg, budget issues, risks, future events, etc.).
7. Review and address any recommendations for action (leave it alone, fix an impediment, stop the work, etc.).  It is possible that different people might have different, even conflicting, suggestions.  And the ET may need to resolve them.

Bear in mind that every ET is plagued by long discussions that often do not lead to any action.  Any EPMO activity needs to address this problem we have with ‘committees.’  Hence, lots of information ‘just to be discussed’ is contrary to what we want.

Outcomes:

• A member of the ET may ask to get involved more.
• A member of the ET may see that his/her department may need to get involved in the future (this should have normally been identified and addressed outside any ET meeting, but the ET meeting is also a place where this might be identified).
• Address impediments.  There are many types of impediments.  One might be: Some chickens are not helping the team of pigs enough, or might cause the release to be delayed.
• Fix certain people issues.  Ex: Direct that someone be added to or taken away from the Team.
• Approve or decline additional budget (or decide to cancel existing budget, ie, stop the work).
• Direct other significant course corrections. (A catch-all for special situations. We have already mentioned most significant ‘course changes.’)

Note: In general, I do not recommend any changes in team composition.  This is usually harmful and usually reduces team productivity. A given set of people may be dysfunctional or lacking in a skill set, so some changes occasionally must be made.  Expect these to be infrequent, and  more in the nature of ‘fixing impediments.’

As implied earlier, each Team will be fixing its own impediments, to the degree it can, and should not have to wait for the ET.  Although, the ET can often help with some impediments.

One of the key issues for the ET is balancing the relative priorities of one initiative against another.  These can change from time to time, for many reasons.  Often the real issue for the ET is that two efforts are contending for the same person or people (people that each Team wants as pigs or people that each Team wants as chickens.)  This must be resolved.

Note: Even a project going well could be stopped, if it has a lower ROI than a new project that those same people might work on. (Obviously, this decision would not be made lightly, and is more involved than I will discuss here.)

Key point: We need the right information to be given to the ET to enable these outcomes.

3. Two types of work

We need to divide work into 2 types: real initiatives for innovation and ‘other work.’

The real problem in life is that we try to do 15 things ‘at the same time’, we end up doing tons of task-switching, and nothing gets finished.

So, the EPMO should only concern itself with ‘real initiatives’.  (How it manages other work is beyond the scope of this blog post.)  If some departments want to or need to do some other minor work, that is for that department to track.   But it is not an initiative that the EPMO should track (or the ET should review).

In accordance with Lean and other ideas, I strongly urge you to minimize WIP (work-in-process). This means, only have as many initiatives going as you have ‘teams of pigs’ to do them.  This will go a long way toward helping to assure the most important business value is delivered first, and quickly.  Putting additional work in process means  the more important things will not get done as quickly as possible.  It also means people will be doing (more) task-switching, which reduces their morale, reduces their focus, reduces their productivity, and reduces their effectiveness overall.  Again, the task-switching delays the delivery of the more important product.

There may also be other kinds of work that needs to be reported to the ET.  But this work is more in the nature of BAU (business as usual), and, again, is not something that the EPMO should facilitate.

4. EPMO’s Role

What is the EPMO’s role?

It is only to help clarify the key information, communicate those information needs, and assure the information comes from the Teams to the ET on a periodic basis.

So, for example, the EPMO should not ‘own’ people (well, except barely enough to manage the information flow — if you only have 5 or 10 Scrum teams, that is probably less than one person). The EPMO does not do ‘real work’…it does not ‘do’ the projects.

One of the reasons to have an independent EPMO is that it does not have any skin in the game, and hence is more likely to be an impartial transmitter of information.

The EPMO must work with both parties (the Teams and the ET) to establish and revise the guidelines for the flow of information to the ET.  This will be an evolving discussion of what is the most useful information, given the cost of gathering the information.

Why?  Because the information flow must balance the needs of the ET against the needs of the Teams.  The Teams want (and the ET wants for the Teams) minimal overhead in producing the information.  Invariably it is not really minimal. Similarly, most Teams do not see the bigger picture, and do not appreciate what information the ET needs to make appropriate decisions.  So, there is always ongoing discussion of the most effective way to get the most useful information to the ET.

Also, assuming the Teams are respected (is there any other choice?), then the Team should attend the ET meeting, to assure the ‘backward’ flow of information from the ET to each Team.  The EPMO might take minutes of significant Team-related decisions made by the ET, but the flow of that information should normally be assured by attendance of the Team.

Here we must digress and speak quickly of the eternal self-aggrandizement of any bureaucratic function. It is the nature of any bureaucracy to seem to want to become larger and make itself more important than it is.  In addition to the extra costs, this slows down and demoralizes the real productivity engines: in the present case, the Teams.  This must be watched for.

5. Information to provide

What information should the Teams provide?

Notice, I did not say ‘what information should the EMPO provide?’  This is because virtually all the real information comes from the Teams.  Each Team understands the meaning and the context of the information.

Certainly the EPMO can contribute a little by helping the Teams understand the information and why it is wanted, and help them in collecting it with the least effort.  The EPMO might have a small role in making the information more ‘transparent’ (more accurate).

In Scrum, we stress the need for transparency.  So, much of the best information can be obtained at the Scrum meetings (the Sprint Planning Meeting, the Daily Scrums, the Sprint Review, and the Retrospective).  If there is ever a question about whether the information given to the ET is accurate, then someone going to some of these meetings can identify whether it is (or isn’t) accurate.

I prefer normal Scrum artifacts be used as much as possible.  This reduces oevrhead to the Team. Or other artifacts that the Team has developed for itself for its own needs. These artifacts are minimally revised (perhaps summarized) and given to the ET.

Here are some ideas about information:

1. Current Ranking of the initiative by the ET. (Is it effort # 1, or # 14?).  The Ranking was (is) based (mainly) on ROI in the ET’s opinion.
2. Green, yellow, red indicator for the overall initiative (in the opinion of the PO). How well is it going, overall?
3. Last release date and Next release date.  (If changed, then also the prior estimated release date.)
4. Release burndown chart
5. Velocity of team over the last 5 sprints (and sprint length)
6. Two sentences by PO on significant scope changes in the current release (adds, subtracts, etc.)
7. Two sentences by PO summarizing other substantive changes in last month (a catch-all)
8. Access to Sprint burndown charts (maybe useful in discussion). (Perhaps via your Agile tool, such as Jira, Rally, Version One, etc.)
9. Expected ratio of BV to cost for the next release. (This is hard for most companies, and may take some time to implement.)
10. Happiness indicator for the Team
11. Full Team average vote (1-5 scale) on the next release (how good do you expect it to be, considering scope, date, quality, budget, etc.).
12. Top 5 impediments
13. Two sentences by the SM about action in the last month on impediments
14. Key risks (if anything substantial)
15. Recommendations of Team (or requests for help)
16. Recommendations of any other parties
17. Any special information for this specific initiative

These are suggestions. Different people and organizations will use others.  These should be evolving.

Usually the main criterion for including or excluding information is this question: “Will this information materially affect a key decision by the ET?”  If the information is just ‘nice to have’, it is probably too costly compared to the benefit.

It is not useful to delay implementation of an EPMO pending some committee or other set of persons deciding on the perfect set of information to provide.  In these matters ‘waiting for perfection’ is ill-advised, and learning from practice is strongly advised.

6. Actions

The ET will often take an action or actions during the meeting on a specific initiative (specific Team).  We would normally expect these to be mainly action on assistance with impediments.  In any case, the EPMO person and the ET and the Team involved should track any actions agreed on.

Over time, there may also be discussions of and decisions on what information should come to the ET. More specifically…

• what information should no longer be provided
• what information should be provided for every initiative
• what information a specific initiative should provide

7. Concluding comments

Finally, let us return to the initial notion.  The ET and management does not deliver customer satisfaction.  That is done, in Scrum at least, by the real Teams.  So, the role of the ET and of the EPMO is rather limited, and in the scheme of things, less important than commonly thought.

This is not to say that the ‘team is on its own’ with no help.  The ET can help a team, or, more accurately, direct that someone should help a team.  So, not all real work will be done by the Team itself.

As a consequence, let us be modest about the usefulness of too much investment in the EPMO and the value of what comes out of ET meetings, at least vis-a-vis direct influence on the Teams.  It is useful, and we must do it, but the benefits are modest.

Two points of focus:
(a) the Teams must do the real work of building product for the customers, and
(b) the Teams are expected to solve many of their own problems, and propose solutions for the others.

There are other functions of management, and the ET would also be involved in them.  But this blog post is about the EPMO, not the ET.

There is another different thing that some senior people provide that is crucial for the Teams.  We often call this ‘leadership.’  The leaders help articulate a vision and a mission that draws out the best in people, the best in the Teams.  It inspires them and gives them a sense of purpose.  This function of leadership is essential, and, when done well, extraordinarily important.  In this view, the ET and its members should provide leadership, not the EPMO.

Some of the key values must be:

• Enable the Team to be motivated
• Get out of their way (allow them to self-organize, self-direct, self-manage to a high degree) so long as they are seeing some success
• Do not burden the Team with ‘muda’ (Lean term for waste) — in the form of ‘reporting requirements to the ET’
• Help the Team (help them with impediments)

***

Your comments are welcome.

 

« « Impediments – Charlotte || Why Managers Should Crave Agile » »