#QuPlan - A Quantum of Planning - Episode 2015/1 - Background - Support Process

Page 1

UPDATE 2015-07-05

#QuPlan #QuPlan discusses the current status of planning and project management, and then builds up on “unconnected” dots to derive a potential evolution of planning concepts

#QuPlan is part of the “Connecting the dots” series, short pragmatic books (generally, up to 60 pages), based on experience and aiming to inspire re-thinking your business ways #QuPlan Episodes Expanding on the #QuPlan book, this (free. online) series of booklets (“episodes”) is a walkthrough within the lifecycle of a fictional business case concerning a regulatory programme

This second “episode” is focused on the “cocoon” built around the programme to ensure that each project is focused just on its own activities, while retaining overall programme coherence

See the back cover for the full list of the planned 2015 episodes

Access to the online version of “#QuPlan – A Quantum of Planning




have been first using, then "augmenting" methodologies since the 1980s, eventually starting in the 1990s to actually design them from scratch, and I still remember the side-effects of methodologies (notably in IT) designed to cope with specific, technologies or processes, i.e. a collection of methods.

It might make sense in some industries (e.g. manufacturing, construction, critical national infrastructure), but in cases such as the one described in this business case a methodology is often a straightjacket designed for yesterday's purposes and constraining everything and everybody into hopeless quests to repeat what worked before.

Any programme delivers a modicum of change, along with its siblings- positive and negative externalities; while traditional books identify negative externalities as a "collateral damage", sometimes they are actually part of the intended yet unannounced consequences of a change programme- a catalyst for change.

This section, along with some other material, is shared between two episodes, as in my experience effective monitoring and support are to be considered two sides of the same coin, the Yin and the Yang of business continuity. PS This Episode contains and references cartoons under CC- if you are the copyright owner and would like to have them removed, contact me.


Š 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning

I will let your choose which side is “Yin” and which one is “Yang”- frankly, it depends on your corporate culture- and in my business experience I really didn’t find “typically male” or “typically female” roles.

In this business case, you will see a quite unusual arrangement, but one that, at least in programme initiatives that were "bestowed" on customers I worked with, was a more pragmatic approach, ensuring that whatever was delivered didn't negatively affect the business continuity of the organization.

If you can choose time, content, budget, and benefits (or deliverables, in the case of a project) to be realized, then you can expect support to have a mostly handsoff or on-demand role, and monitoring to focus on compliance with internal rulesranging from quality to knowledge management.

But often, even under the best conditions, your plans cannot consider all the potential evolutions of your business environment- including the motivation and willingness to cooperate of your stakeholders, e.g. the public or political representatives that will be affected (or competitors’ countermeasures adopted by them once your programme started becoming visible).

Support and monitoring staff are here considered as the ones fulfilling "ex-ante" roles, i.e. they are part of the lifecycle of your programme.

Obviously, if you properly deliver your activities, any "ex-post" audit should be a mere formality: whenever it is not, either something didn't work as it should have done, or the "rules of engagement" weren't properly defined and communicated.

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning


There are two elements that I consider within "backstage" activities (from the inception to the end of the activities):


•helping those charged with delivery to carry out their own activities without re-inventing wheels that are already available "in house" (unless. of course, the aim of their activities is to re-invent the wheel)


•what usually is meant to be a form of control of compliance (but, in this business case, it will be something more than that, supporting business continuity)

This "episode" is focused just on the "support" process, i.e. the convergence of corporate/organizational resources into delivering services that help project and programme teams to create momentum for change and (hopefully) achieve the agreed aims of the project or programme, while coping in an appropriate way with unexpected changes.

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning

Project and programme teams easily develop a "tunnel vision" focused just on what is respectively within their scope or business blueprint, despite all the hype about "stakeholders".

Support staff (methodology, PMO, etc.) should help teams to keep in mind that their efforts are part of a broader environment.

In my experience, support without monitoring is often more a nuisance than help, and monitoring without support is a Kafkaesque situation where you never know what you did wrong, but somebody will certainly tell you.

In any environment where more than one activity is going on at the same time, there is usually a set of rules (formal or informal) that defines what can and cannot be done and how.

Often there are other rules- ranging from roles (and who can cover them), formal rulebooks (a.k.a. methodologies), and "allowed" tools.

While the first episode was focused on the overall concept of this business case and a discussion on the tools, this one will be the first to look at what usually isn't considered in business cases: the "backstage".

The question that this episode aims to answer is quite simple: when is support supportive, and when it becomes a nuisance?

Š 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning


While other business areas probably have a focus on specific skills, support roles require a significant investment on "soft skills": a permanent member of a support organization needs infinite patience, as probably listening to ranting from those that (s)he supports will be routinely needed, if (s)he is to obtain the information needed to provide meaningful support.

The risk? Getting on board people for their specialist skills, and then being surprised if they try to focus on efficiency in support, not on efficacy: a certain degree of self-effacing humour is always useful for those working in support.

The most difficult part is to convert somebody used to be on the frontline to a support role: as a "supporter", you have to provide advice that might not necessarily be followed (more about this in the next Episode, on monitoring)- and that obviously isn't something that those used to lead others or execute accept; often I saw some seeing as their own mission to “convert” others to their obviously superior wisdom, taking over a role that belonged to those that they supported.

A destructive risk is to have people assume a "bureaucratic" stance- hence, the choice of some organizations to "loan" staff from operations to support offices on a rotating basis, to allow a continuous "reality check" from both sides.

The best support organizations in my experience where the ones that were invisible- except to those that used their services: and this is certainly the first element that should guide in selecting who is part of a support organization.

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning

Should you create two separate offices?

What is the difference between support staff and monitoring staff (the latter being the subject of the next episode)?

Consider support staff as an extension/expansion of the delivery teams that is helping "bridge" knowledge versus corporate/organizational standards, e.g. knowledge management/retention.

Instead, monitoring staff (which could include people who belong to the support staff on other activities, but cover the "monitoring role" on our programme or project) should be considered a kind of "feed-back staff", not focused on a mere "drum beating" (as a PMO, since the late 1980s I considered my role to be split between supporting and monitoring, only occasionally just auditing “ex-post”).

In my experience, monitoring and support should be considered two roles, not two separate organizational structures, to ensure that any activity delivers information useful to expand the "corporate/organizational memory".

Assigning the two functions to separate offices (moreover if one or both are staffed by consultants, not people who share your own corporate culture), as well as assigning the "memory" role to somebody else, could actually result in the typical troubles of way too many knowledge management initiatives (see BFM2013 and BSN2013 at robertolofaro.com/books): whatever they deliver cannot be evolved by those who actually know the domain, and those working on delivery will feel that they are dealing with a left hand that doesn’t know what the right hand is doing.

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning


If you read the previous sections of this chapter, you probably noticed that "communication" is a keyword scattered or hinted at here and there.

Tools have to include what is useful to identify issues ASAP, while also gradually building the "memory" of the activities (as this could affect continuity and future initiatives).

Moreover, the "knowledge bridge" role (internal vs. external, and external vs. internal) demands something more than just exchanges of emails (which, incidentally, usually are so unstructured that real information is scattered, by design or by accident, across so many bits and pieces, that often only way too late the "pattern" is discovered).

Communication being the key, I usually adopted a mix of tools (online forums, mailing lists, cross-checking progress spreadsheets, business intelligence dashboards, weekly or even daily mini-meetings, delivery of a “knowledgebase/captain log CD” after the project ended) tailored to each specific environment and organization - do not use a tool just because you have staff members able to use it!

Support staff should help in selecting the appropriate mix of tools and guidelines or templates before activities start, as part of a negotiation between potentially (often) conflicting sets of aims.

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning

A minimum set of tools for the XXI century support roles

Any support activity that is really working along with the delivery and benefits realization teams will generate various levels of information- ranging from what you would like to see in a final report, to advertisement/morale building material (for both internal audiences and external stakeholders), to something that could be described as “structured ranting”.

The key issue is: you should find ways to keep track of everything that affected decisions, as it could be used to avoid reopening decisions that had and still have a sound basis; often, due to “business politics”, what stands on official minutes is simply useless to convey the rationale behind choices.

Online forums, internal blogs, mailing lists, Whatsapp, secret Facebook groups, Google+ circles: the tool doesn’t really matter- what matter is that your toolset is consistent with your corporate culture.

The heralds of absolute transparency should first get approval from the top to dispense of the too common attitude “we make no mistakes here”: who would communicate or share otherwise? You would just generate a powerful “Speakers’ Corner platform” for those looking forward to surf up in the corporate structure with the minimum effort, possibly by dumping any hot potato onto somebody else.

Externalities sometimes are planned, but, as risk, evolve- and the sooner their evolution (positive or negative) is highlighted and properly shared/integrated within communication activities, the better.

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning


If you have a look at the template documents provided by PRINCE2 (for projects) and MSP (programmes), you can easily spot that what is there is probably an overkill for most projects and programme activities- and not just the fictional compliance case that is discussed through these "episodes", or "agile" projects and programmes.

Again, the quantity and quality of documentation should be part of a negotiation involving programme (or project, if there is no programme) staff, support, and monitoring, e.g. by delivering a minimal level of communication that is recognizable by stakeholders who probably are affected by more than one project or programme, instead of having a whimsical project-by-projectstandardization, and letting the audience to do the integration (a common occurrence in business, as discussed in the previous episode).

It might well be that the communication depth, width, and frequency will vary. E.g. developing a multimedia presentation movie to chart progress might be a waste of money for activities with a short timeframe and a professional audience, while it might make sense when the stakeholders are political action groups, the general public, or organizational units scattered around the world.

Therefore, support staff should also act as a collaborative "communication channel" to let what is happening outside the limited programme/project boundaries known to those inside, and see if what is evolving within those boundaries affects or could affect others.

Š 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning

How not to document

From a delivery, support, monitoring, and budget management perspective (some of the roles that I covered), the current obsession with Powerpoint slides used for everything (from communication to analysis and requirements or deliverables documentation) is a waste of resources (I will expand on this within the “Thinking” chapter, under “costs and benefits”).

The minimal information that should be kept, shared, evolved (with the appropriate degree of variation according to the specific purposes) has to be consistent not just with your corporate or industry standards, but also with the expected lifecycle of your project or programme.

Whatever your methodology, you should keep track of progress toward targets (your business environment doesn't freeze until you complete your activities, and therefore targets might evolve), communication (to ensure that everybody is kept in the loop), decisions made (both positive and negative ones), risks and associated costs (to help delivery teams adapt without wrecking the ship).

Overall, the concept should be: delivery (or benefits realization) is paramount, but if what is delivered is useless or cannot be managed, it is a waste of resources.

Documentation should be focused on an optimal balance between reducing costs, compliance, and ensuring support to whoever will “inherit” what the project/programme will deliver, so that they can adopt (past practices) but adapt (to their own contemporary business and, in this case, compliance needs).

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning



If you work long enough on projects (not just in IT), eventually you will see a chart showing a swing as developed through the phases of a project (by the inventor of Dilbert, it seems1)- I saw it first in 1986 on my first mainframe project, but others on Linkedin wrote that they saw it in the 1970s; anyway, it still holds true.

There is always a distance between expectations and reality, but when the timeframe is short, and there is a seemingly endless list of activities, I observed both extremes: from those who were focused and clearly identified where we were heading to as well as our priorities, to those who simply planned a dream.

In this phase of our business case, the next sections describe how I would approach the delivery of support if I were tasked to support a compliance programme such as the one described in "Episode 2015/0".

In this and the following episodes of #QuPlan, this chapter contains a "storyline" adopting each time the perspective of a specific part of those involved- in this case, the support team.

Within this chapter, the left-hand page contains my commentary, while the righthand one presents excerpts of what you could get through the activities.

In some cases, part of this information will be expanded in future publications.

E.g. http://www.bayarchco.com/Main%20Frame-Philosopy.htm

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning

From the audio recordings of the meeting of the support&monitoring staff after the initial decision making (continues)

The programme in barely 6 months will have to deliver 18 projects of various sizes, some of them concurrent, and our resources will be stretched, as there will be more than once a "training" component where we will both help in preparing the material and deliver the actual training, to speed up the process.

The detailed plan will be developed during the first month/first project, that is focused on assessing feasibility (“how”, not “if”, in this case) and identifying the detailed roadmap [follows discussion of the material in Episode 2015/0].

To be frank, the legal requirements that generated the need for this new service and therefore the programme is... a work-in-process: changes are to be expected.

This first joint meeting will be followed by meetings focused only on monitoring. To summarize, as support, we have been asked to: 1. carry out our traditional role (coaching, helping to apply standards, etc.) 2. ensure that a minimal amount of cross-project information is available daily and consolidated weekly, so that we can immediately spot potential issues and discuss appropriate measures to evolve the delivery plan 3. be on-staff advisors and hands-on consultants on the use of the methodology within each project, as most projects will be led by a part-time project manager who happens to be a subject matter expert, not a project manager 4. collate documentation within each project.

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning



In Italian we have a saying: “la montagna ha partorito un topolino” (the website 2 where I found the cartoon is referring to environmental issues); and this applies also to project and programme management; in English a similar yet different (perspective) concept is “much ado about (next to) nothing”.

Obviously, those from the “agile” side would say that this applies just to “traditional” project and programme management, but, in my experience, the first element of “agility” should be to understand when each approach should be used, not assuming that you have “the” hammer and turn any activity into a nail…

In this fictional programme, there are projects that are “more of the same”, i.e. where what needs to be done is nothing new- it is the combination of all the elements that is the novelty (it happens often in service definition activities- worked a couple of decades also in outsourcing/BPO).

Therefore, the programme management per se in this case will need to be “agile” once the roadmap has been defined, to avoid the typical mountain that delivers a small mouse (and the associated re-invention of an already existing wheel, something that we in IT are routinely asked to do).


© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning

From the audio recordings of the meeting of the support&monitoring staff after the initial decision making (continues)

The obvious starting point is prioritizing, as in reality some of the projects are nothing more than what we did for [here would refer to another new service to support].

We will help the teams assigned to those projects to replicate or tailor what worked before and is supposed to be still appropriate, and act as business analysts under the subject matter expert/”project manager light” in projects where that prior experience is either not available, or not relevant anymore.

This way, we will also ensure that e.g. interviews, minimal documentation, and consolidation of information will be done in such a way that it will be later easier to retrieve and update.

It is therefore critical to consider those of you assigned to support as members of each team and experts in our approach to knowledge retention and management, not the other way around, otherwise we will be the bottleneck of each project.

Obviously, we will need to have ways of routinely checking where we are heading to, also to clarify as early as possible any discrepancies- on this task, those assigned to the monitoring role will keep doing a “continuous reality check”.

Last but not least: “documentation light” yes, but “documentation later” no.

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning


As discussed in Episode 2015/0, there is a significant chance of re-iteration of one or more of the activities/projects, and therefore the support roadmap identifies the roles that support staff assigned to each project (or to multiple projects at the same time) has to carry out, interacting with the project manager/subject matter expert (SME).

This is just an example (see next page), but the roles identified for support staff in this programme are as follows (yes, negotiation/assessment of the needs):

Support role

Mixed role

Operational role






•Business analysis support •Support (i.e. generic on standards' application) •Support in accessing knowledgebase and structuring information retrieved or collected •Support and cross-referencing to guidelines from CIO+CFO (i.e. investiment and procurement) •Support training design •Support and jointly deliver coaching •Business analysis (under supervision of the SME) •Deliver training •Documentation

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro



Access to the online version of “#QuPlan – A Quantum of Planning

PROJECT 1 identify feasibility 2a define service requirements 2b define service location 3a design service 3b design communication and pre-emptive marketing 4a1 prepare service 4a2 prepare service environment 4b test service with pilot customer 4c train staff for initial svc 4d pre-emptive marketing 5a coach on-the-job initial staff 5b monitor at customer site 5c marketing campaign and lead generation 6 tune service 7a retrain staff 7b acquire further staff 8 transition to Business As Usual 9 closing down programme and thesaurisation

ROLE Business analysis and support, cross-referencing to guidelines from CIO+CFO Business analysis and support, cross-referencing to guidelines from CIO+CFO Support and cross-referencing to guidelines from CIO+ CFO Support in accessing knowledgebase and structuring Support in accessing knowledgebase and structuring Support in accessing knowledgebase and structuring Support in accessing knowledgebase and structuring Business analysis support and support, documentation Support training design and deliver Support in accessing knowledgebase and structuring Support and jointly deliver, document Business analysis support and support, documentation Support in accessing knowledgebase and structuring Support in accessing knowledgebase and structuring Support training design and deliver Support in accessing knowledgebase and structuring Support in accessing knowledgebase and structuring Support in accessing knowledgebase and structuring, documentation

Š 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning


3 4

As discussed in the introduction to this Episode, I see support and monitoring as two sides of the same coin- and this applies also to the use of tools.

If you read the book that these “Episodes” support 3, you know that “prioritization and communication” are, in my view, two key elements of both project and programme management, as any project/programme manager who thinks that (s)he can dispose of either is at best delusional.

See any project or programme as something that interacts with an environment (yes, the stakeholders- including internal stakeholders), and try using those nice “heat maps”4 (that many use for risk management) to continuously monitor also their feed-back.

You can obviously use a new project or a new programme to experiment with tools, but always cross-check with your “heat map”: if they are “uncommitted” to your activities and their role in it, probably using what they are used to as a communication channel is the easiest way to avoid making more enemies than you need.

In some cases, you might want to deliver a new communication tool as a way to “engage” specific stakeholders: beware - if mismanaged, it is perceived as manipulation/monitoring, and can easily backfire.

Available for free on http://www.robertolofaro.com/QuPlan http://en.wikipedia.org/wiki/Heat_map e.g. issue/channel vs stakeholder vs level of commitment

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning

From the audio recordings of the meeting of the support&monitoring staff after the initial decision making (continued)

I know that you all are almost “digital natives” and carry around (also those of you with white hairs like me) half a dozen tools and keep opening conversations on one and then continue on another one.

Consider: 1) in barely six months, we will have enough activities to report on to be able to generate a cacophony; 2) there is the risk of conflicting messages: what you write on Twitter assuming that everybody read all your previous emails might reach an audience that resolutely refuses to open the email inbox during the week.

Therefore, our first task is to help identify who are the stakeholders involved, and which channels should be used to communicate with them, and which messages could actually generate more issues- so that we remember to always strive to be consistent in communicating across channels and across audiences, and, whenever possible, use what they are used to, avoiding “mail storms”.

As an example, weekly progress reports showing where we are across projects and across the programme will be available through the dashboard that our internal and external business users routinely access- it is just yet another use of our customary business intelligence tools; Microsoft Project details will be available but kept within the programme teams, while a summary Gantt highlighting where we are, what happened, where we will go next, potential risks, and external events that could affect that, will be available in our programme forum and mailing list.

Furthermore, [description of use of social media internal/external to share status]. © 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning


As you probably already recognized within "Episode 2015/0", my approach is based on the idea that what matters is delivering something that is useful for the organization requesting it- and anything else plays second fiddle.

I worked with and for various support organizations since the 1980s, but generally what works best is... what works best for you (a special mention goes for the misuse of Powerpoint presentations, notably by me and my fellow consultants colleaguesbut I will let the Washington Post explain the costs and benefits of slide decks 1).

The critical risk, as I discussed in the two books that I quoted before, is to avoid that support staff loses touch with business realities: taking experts from the operational activities and transferring them to support offices while never again involving them into business as usual is the “best” way to ensure that the longer they stay there, the more their balance between theory and practice swings toward the formeralbeit they seem to be the only ones ignoring it (I have been guilty of that too).

While in larger organizations there is an obvious interest in ensuring that there is a degree of harmonization, the risk of support offices staffed only by experts is that they will deliver a negative contribution both to individual projects and to corporate goals, e.g. by piling up documentation requirements across the board, requirements whose basis is only their own internal structuring and classification needs: service-orientation (i.e. “does the customer need it?”) is paramount. 1


© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning

Keeping a continuous balance between costs and benefits isn't something that affects only support/monitoring.

While projects delivering physical objects usually have a clearer perception of reality, projects focused on delivering immaterial goods often have a "perfectionist" approach at the beginning, followed by a decreasing level of attention when the delivery deadline approaches- a "fix it later" approach.

Obviously, projects that follow iterative or agile methodologies, and require a constant interaction with stakeholders and "owners of the results", reduce this risk by having from the beginning to build a pattern of satisfactory results with their customers.

If they are short; the longer they become, the higher the risk that stakeholders will be bored to death by excessive crossing the Ts and dotting the Is in the quest for a perfect bullet, and simple tune off: the novelty of being involved fades fast.

Nonetheless, the longer the project, the higher the risk that, eventually, some business users will feel "attached" to the delivery team, and therefore alter their own perspective, falling into the above mentioned patterns (I saw it in few countries)- they start representing the solution, not business interests.

Part-time and on-demand support staff can help in keeping the costs-benefits balance that was agreed as the overall target for the programme or project, even if acting just as an audience for business users and delivery teams, by asking the right questions, from a "continuity" perspective.

Š 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning


2 3

If you are in a tunnel, you do not necessarily realize how long you will be in it (hopefully, it will eventually end- not as in the cartoon2).

I have been on many projects (in various roles) where being the only team member that was parttime allowed to foresee potential needs for further support- before it was asked (yes, a part-time project manager and business analyst covers also support and monitoring roles).

A typical issue on many projects, as discussed by a recent report from PMI on requirements management3, is the inappropriate mix of skills.

Sometimes, this can be identified during the feasibility or budget definition phase, but sometimes this becomes clear only after the project starts and part of the business analysis turns into deliverables that are unsatisfactory.

An approach that I found useful, also for “evangelization purposes” on new methods or approaches, is to invite them to be temporarily part of support staff, or join them, as I showed in the business case, as a team member, as in both cases this helps in harmonizing expectations, “standards”, and reality.

https://emprerdedorglish.wordpress.com/tag/personal/ http://www.pmi.org/learning/requirements-management.aspx

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro


Access to the online version of “#QuPlan – A Quantum of Planning

A corporate support net

Thanks to their cross-project, out-of-the-tunnel perspective, support staff (more than those tasked with monitoring, who traditionally have a less cooperative relationship with projects that they monitor) can identify specific training needs or skills mix alterations (e.g. because the complexity of specific parts of the project/programme has been increased by external events), and provide a helping hand to more junior project managers.

A further element that support staff can contribute to the projects or programmes that they support is cross-feeding information with other projects or programmes.

If there is an issue, e.g. the actual preparedness for work of those trained by a specific course is inadequate, they might check projects across the board before that could become an issue elsewhere (training “Big Bang” approaches can generate “ripple effects” that, if unchecked, could generate a “resonance” 4).

A typical example is projects introducing new processes or technologies without having first a "pilot project" that is realistic (if you let suppliers choose the pilot project, they will usually go for what makes them shine, not for what represents your everyday needs).

Support staff can bring back to reality some project managers who, instead, are excessively cautious, raising a flag whenever there is something happening that wasn't forecast (more about this in the last section of this chapter). http://en.wikipedia.org/wiki/Tacoma_Narrows_Bridge_%281940%29

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning



Usually, documenting and collecting what happens during a project is something that, in my experience mainly in Europe, is at the bottom of priorities for any project team- and often it is a task left to interns or junior team members at the end of project/programme activities (been there, done that).

Instead, thesaurisation is and should be part and parcel of any project or programme manager toolset, as it is an element of two key skills that, whatever the methodology and size or industry of the project, I saw consistently deliver value: communication and prioritisation.

Yes, you read about it few pages ago- but it is worth remembering. You cannot communicate effectively unless you kept track of what you communicated before to the same audience (and their feed-back to your communication)- as you saw in the “Business Case” chapter, there is direct traceability in communication across the activities (in this case, between Episodes).

While some methodologies have extensive and intensive documentation demands (I worked with some), if you are managing a project or a programme you need to have readily available at least what supports your communication and prioritization, with appropriate tools and staff, if that is what is needed (e.g. in environments with established corporate portfolio management approaches 5).


© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning

Nonetheless, except in more structured environments (i.e. those measuring themselves against the CMM maturity level from level 3 up), usually support should help also in defining "ongoing" tailored thesaurisation approaches, to avoid the two extremes that I saw in project and programme management.

Yes, there are those who document everything down to the tiniest detail according to standards, and even develop their own “project standards” to expand on that; and those who adopt a "whimsical" approach to documentation, starting to document only after a major crisis.

This subject will be discussed again in the next episode, as thesaurisation is something that should affect all those involved in the delivery- including those supervising, monitoring, auditing, etc.

If you and your teams produce a minimum of information that is functional to your own activities (including communication), your thesaurisation will develop organically, as a natural side-effect of what you have to do, increasing the chance that whoever will create anything worth entering your “knowledgebase” will be the person with the appropriate skills, at the appropriate time- and with the appropriate knowledge and resources available.

Thesaurisation requires skills, timing, knowledge: if one of the elements is missing, you risk to discover much later (it happened) that your nice, structured, goodlooking documentation was nothing more than mumbo-jumbo, sometimes hundreds of pages of it.

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro

Access to the online version of “#QuPlan – A Quantum of Planning


I cannot really remember projects and programmes where everything went as it had been initially planned - and support staff needs to help project teams to relativize change.

Thanks to my experience in the dual role as project manager in some cases, and change manager in others, more than once I was told by project teams that I was the only project manager that they worked with who, when change suddenly appeared, was either already prepared, or negotiated a way through it- I was even once nicknamed “robofaro” (a play on my name and surname and “automated buoy”- but I received less appreciative nicknames as well). Ideally, I think that any project/programme (and in some cases also portfolio) manager should be well-versed also in at least organizational and technological change (and, in compliance, also cultural change)- but support staff can act as an internal consultant in staff to the project manager to cover those domains.

I will skip discussing the sources and types of change- there is plenty of material about that.

I selected a "compliance" programme as a business case because, despite the "critical" elements that I added (i.e. the short timeframe, potential volatility within the regulations), a programme that you deliver due to external demands usually comes with a more defined set of requirements, deadlines, etc.

© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro


Access to the online version of “#QuPlan – A Quantum of Planning

On the opposite end of the spectrum, "emerging programmes" (something I worked on often), to follow MSP terminology, are quite volatile, as obviously a project that grows in size and acquires/”spawns” further projects and activities (even services) along the way is generally a moving target, and keeps moving and expanding while there are resources available- or patience from management or the stakeholders subsidizing it ends.

In emerging programmes, the risk is always to be able, as a programme manager or within the PMO or similar roles, to understand that having spawned something doesn’t imply that you have to keep controlling it: if it is a service, it is better to shift it under a permanent, service-oriented structure, or even see if a new programme is needed, while having been the original project manager doesn’t necessarily qualify you as the programme manager.

At the programme level, you usually expect that managers and directors have a significant amount of experience with change and its impacts.

At the project level, this is less common, and, as described in a previous section, sometimes project managers freeze when something changes, or keep moving the target by using their persuasion skills.

An example is described within an old (2010) but still useful short essay on the use of PRINCE2 and MSP together6, worth reading, along with the business case on the 2012 Olympic games.


© 2015 Roberto Lofaro http:/www.linkedin.com/in/robertolofaro