#QuPlan - A Quantum of Planning - Episode 2015/0 - Business Case and Product Comparison

UPDATE 2015-07-03

#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 first “episode” shows the initial decision points, i.e. an

outline of the overall programme, key fact-finding, and the

choice of methodology, tools, key staff selection guidelines

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

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

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

INTRODUCTION

I designed a realistic but not real case, focused on compliance to fictional new

legal requirements- and the table above lists some key elements of the corporate

culture.

The business case covered by the #QuPlan episodes was created to exemplify

typical issues that are part and parcel of any initiative involving change- with and

without technology.

This business case will be used in 2015 to support other books, and in this first

episode both the methodology and business case will contain introductory

material..

•any issue that is known can be managed as a risk

•any risk has to be managed to lower its impact

•no “pushing downstream”

Transparency

•awareness independent from a hierarchical mandate

•those who know by being on the frontline, notify issues

•aggregate their notifications and potential solutions

Emergence

•No tolerance for "corporate whodunnit"

•teamwork has to be routinely multidisciplinary No Whodunnit

•Consistent and continuous thesaurisation of lessons learned, and availability of tools to support that

Thesaurisation

http://www.robertolofaro.com/books

http://www.linkedin.com/in/robertolofaro



Any regulation requiring to alter processes and organizational structures usually

implies also impacts on existing IT systems, but almost never legislators and

regulators have “in house” the knowledge required to assess business impacts, and

therefore generally there is a chance (few months, few years) to submit comments,

suggestions, etc.- before the final version is promulgated.

Stated aim of the fictional law: ensure that those interacting with consumers have

the knowledge and skills required to comply with current regulations, by extending

the approach already used e.g. to recover discarded electronics- it is suppliers’

duty..

The selection of a case about compliance allows to skip over some of the most

critical/”political” activities: if it is required by law, often a “quick and dirty”

approach is followed to minimize costs while ensuring compliance- what matters, is

identifying an appropriate balance between risks and costs.

In various cases, I saw that emerging programmes based on compliance were

used as an excuse to overcome resistance to change, expanding the scope of the

activities to cover what had been needed for a while, but kept on the back burner

while waiting for the appropriate combination of tools, motivation, and

opportunity.

Yes, if you do not attach to your “charter” a clear definition of the aims, purposes,

and rules to be followed, lessons learning turns into a CSI investigation.

Obviously, it is a risky choice, as once you start expanding the scope, often it keeps

expanding- with a “bandwagon effect”: with each expansion, it becomes more

difficult to deny further expansions.





A SAMPLE/SIMPLE METHOD

This first episode is called episode zero, and outlines the rationale of the business

case, adopting a “storytelling approach” that I used decades ago in business to

have employees of a banking customer learn a new methodology and approach

to project management.

The programme roadmap is based on the concepts and lingo of MSP (basically,

the programme management side of PRINCE2), by OGC.

As any “designed” case, this too needs to be adapted to your own specific

business constraints.

The purpose of this business case is to share information about how activities could

evolve, as an excuse to discuss various elements and potential evolutions of

programme and project management discipline outlined within the book #QuPlan.





As you can see from the map within the previous page, the contents of this

booklet cover the first phase, the definition of the mandate for the activities, i.e.

this first episode focuses on just part of the “Define” step.

Obviously, there are countless ways to deliver a project, and therefore I identified

one that covers the general steps shared by most methodologies (in some cases,

re-iterating more than one step).

Whatever the methodology that your organization selected, it is anyway advisable,

before starting any project or initiative, a review with the “guardians of orthodoxy”

(methodology, quality, etc.) to cross-check what is applicable, in terms of rules,

standards, and tools- both to avoid re-inventing the wheel, recycle what might

now be obsolete or non-compliant with current rules, or risk getting on board rules

“suggested” by suppliers (e.g. software packages and service vendors usually

implicitly follow their own rules, to optimize the use of their own resources).

This “episode” includes a quick review of the options available in terms of toolsets

to be used to support programme/project management, to enable tracking the

allocation and use of resources while delivering what has been agreed as the

stated aim(s) of your initiative, but without excessive overhead.

obviously, in a real environment usually the tools have already been chosen, but in

this case the tools that have been identified are those represented within the map

shown in the next page.





TOOLS SCENARIOS

•Using just Office productivity tools

•Files stored on a network or directory structure

Office productivity

•Microsoft Project and Microsoft Sharepoint

•Integration with Office productivity tools Standard

•Potentially multiple vendors involved

•Need to work through a stricter «stage-based» approach

Workflow

•Either off-the-shelf or custom, but access and integration via Internet (including WAN Intranet or Extranet)

•Chosen an open source solution that I used to support start-ups

Online platform





Each tool has different strengths and weaknesses, but all share a common

element, the ubiquitous Gantt chart, representing the mutual dependencies and

sequence of activities; you can use the tools both at the project, subproject, or

programme level.

There are further shared elements, e.g. features to list people (“resources”) and

financial resources or costs, but for the purposes of this product comparison, as

those features are shared; whatever combination of tools you will choose, you will

need to be able to do at least the following:

Whatever tool you use, you need to consider that no organized activity can

survive without a communication plan that is prepared before the activity starts-

and this requires thinking about the audience(s) that you want to reach (a.k.a.

"stakeholder(s)").

pro

ject

man

agem

ent

kno

wle

dge

bas

e

to collect preliminary data, refine guesstimates, produce a “baseline”

to associate costs + people to activities, and track their allocation

to have instantaneous access to the current status of ongoing activities

to have a copy of each relevant document (minutes, timesheets, etc.)

to associate each document with the source/destination activities





AUDIENCE OVERLOAD

Information level Complexity level

I have been using Microsoft Project and general-purpose project management

tools for decades, and I still consider that most of the “standard” reports that they

produce are simply useless for both project managers and stakeholders.

This diagram presents the “complexity level” in information sharing, stating how

“knowledge-intensive” is the understanding of a chart, ranging from “intuitive” (if

you see a sequence of bars across a timeline, you know what they mean), to

“logic” (you need to at least grasp the concept behind the formalism), to

“quantitative” (you need to understand how the representation is created tomake

sense out of it).

Gantt

CPM

PERT

Intuitive

Logic

Quantitative





Both the project manager and stakeholders focused on few bits of information,

information that was actually partially misleading, , converting tools such as

Microsoft Project into a kind of “Excel less the formulas plus the Gantt”.

If Gantt, CPM, PERT are meaningless “alphabet soup samples” to you, have a

quick look on Wikipedia (or wait for the “Thinking” section)- basically, they are

three ways to represent how activities are delivered across time.

The first is a century old tool, derived from the manufacturing planning needs of

the early XX century, while the other two are roughly side-effects of the more

complex manufacturing needs of the early Cold War (e.g. building nuclear

submarines and power stations).

Tool designers, assuming that there were other “standard reports” on risks and

impacts, simply removed from the basic reports information on the confidence

level of the information provided.

It makes more sense to identify, within your guidelines for project managers, which

reports are required, and few lines about each one of the “standard reports”

available, to explain the who/what/when of their production.

A further element to consider is how and when to spread information: while for a

simple project or programme it might make sense to release information once in a

while, in some cases a continuous information stream is required.





COMMUNICATING

Whenever stakeholders are both spectators and actors, i.e. when they are not just

a passive audience, communication implies something more than just sending out

files..

In the past (e.g. 1980s and 1990s), this required investing in tools or custom

applications, but in 2015 any company uses a form of spreadsheet that is able to

present data using what, until few years ago, would have required an investment

in business intelligence or dashboard presentation tools.

Since the late 1980s, I saw complex systems delivering DSS, EIS, management

reporting, dashboards, business intelligence, data warehousing, and an assorted

software paraphernalia that seems to be constantly mutating every couple of

years.

The risk with IT is always that the tool takes control- notably when, due to the

number of options available, instead of delegating just the execution, also design

is delegated to somebody who has no understanding of the business processes

and business people involved (typically, an intern or temp worker, no matter how

experienced).

In most cases, the anxiety from those that were assigned to the use of the tool took

over the purpose (quick but consistent and continuous information dissemination

to decision-makers or stakeholders), creating either system too simple and static

(for fear of misuse by the end users) or too complex (to “empower” them) for any

real use.





Within this business case, there will be no sharing of minutes, reports, presentations,

project planning files, templates, etc. relating to this phase, as the release of files

(e.g. Gantt, presentations) is scheduled to be part of the last “episode”, on

thesaurisation, where the theory and practice of “knowledge retention” will be

explained.

I assume that you can find templates online, if needed (links provided under the

last part of this chapter, if you need immediately templates etc.).

It is worth anyway repeating: if you belong to a large organization, probably there

is a 'modus operandi' in communication that you have to follow.

It is something that often consultants forget- customers should remind them that

they are paid to fulfil a corporate need, not to promote their own methods or

standards.

There is another not so small issue: most project and programme teams often

forget that those that their stakeholders probably are on the receiving end of

plenty of communications.

What matters is consistency in communicating relevant information and timely

collection and management of feed-back.





ENGAGEMENT TOOL

Does this sound familiar? To me, it does- since the late 1980s! Also when everybody

is using a smartphone, there are still endless technologies that are dumped on

users’ computers, as if information dissemination ended once the information is out

of your door.

Manager A needed to communicate continuously progress on activities (business, service, project) to Manager B

The staff member for Manager A eventually “evolved” the tool, and it became “too informative” (a.k.a. hair-splitting)

So, Manager B delegated to one of her/his staff members the task to routinely verify completeness of the information provided, and summarize what (s)he saw

Result: those who less understood what was involved became the communication channel, and the tool eventually expanded to add more information that to them seemed useful, further distancing their own managers from even daring to approach and use the tool- so that Manager B, in effect, turned to a “seat of the pants” decision-making approach





In most cases, this can be easily solved: streamline- both the information collecting

and processing tasks, and the presentation tool; if a tool delivers 100 features, and

you need just 3, once you have the tool in house, why should you feel compelled

to use the other 97?

In other cases, a “re-education plan” is needed, as deciding which information is

relevant to decision-making should be up to the decision-makers, not their number

crunchers (and I designed once a system that, while using just a handful of data

already available, was able to show progression and send shockwaves on specific

issues, without any need to create a “number crunching bureaucracy”).

Many larger organizations have in house a business intelligence tool, or just the

humble-yet-powerful “Excel Power Pivot”: an appropriate mix of data collection

and streamlined “dashboard” design can turn both into tools able to provide

much need information about a portfolio of projects or services.

The key issue is to have data reach (and be “consumed”) by those who really

know them: a PMO that provides just reporting and no organizational

development support is not always needed, if you have already a management

reporting function available.

In future “episodes” (2015/1 and 2015/2) a different approach to reporting on

project/programme management will be discussed.

The last section of this chapter contains some guidelines on documentation

lifecycle management.





DOCUMENTATION

If your organization lacks formal standards, you may have a look at samples

published online, e.g. those provided, free-of-charge, by PRINCE2 1 ; it is also

advisable, before using those documents, to read some guidelines (both

documents require a free registration on Axelos, the company now managing

OGC’s methodology frameworks).

Phase 0: Definition It is advisable to attach to the “charter” the guidelines for

documentation production and delivery, including who/what/when/how, and any

“license to deviate from recognized corporate standards” (e.g. for shorter projects).

Phase 1: Ongoing Generally, documents are to be produced as soon as the

information is available, e.g. minutes of a meeting should be composed/drafted at

the end of the meeting, and shared as soon as possible- and anyway before the

next meeting involving the same people (as meetings should show progression, not

just that you had a schedule with X meetings each week!).

Phase 2: Thesaurisation Every project eventually ends- and this includes also

projects that are cancelled mid-way, or just scrapped before they even start (yes,

it happens, sometimes- and some lucky ones get even paid for work not done).

Unfortunately, once the adrenaline rush usually associated with the delivery of the

last leg of a project is gone, the first thing to disappear is the motivation to review

what was done.

1 https://www.axelos.com/best-practice-solutions/prince2



https://www.axelos.com/best-practice-solutions/prince2



Your documentation should include both positives and negatives choices- as this

could be useful to avoid in the future to get through the same decision-making

routine, just with different people (with the potential that they will not understand

the logic of your choices).

Sharing both sides of each decision, along with the rationale, is useful also to help

keep whatever your activities deliver to adapt to changed business needs.

What was relevant when you made those choices might not be relevant anymore.

Thesaurisation is an activity whose usefulness rests on few basic elements:

1. Knowledge-based: it has to involve those who know (and not just the cheapest

ones available or those who cannot refuse to do it)

2. Timely: it has to be done immediately after the end of the project (actually, it

starts while the project is still ongoing)

3. Talking straight: it has to be done while avoiding any “politically correct”

scribbling (you have to say how it is/was)

4. Accessible: last but not least, it must deliver something that is then accessible

to others that might use it (e.g. by adding an “executive summary” or

“documentation roadmap” for future uses).





EXECUTIVE SUMMARY/1

A recent change in a national law [reference] extending on a European Directive

for consumer protection [reference] introduced, with just one line within the law,

the need for the creation of a new information service.

The stated aim is to ensure that agents and distributors of our products and

services are always compliant with regulations that could potentially affect their

business operations, and how they interact with customers obtaining our products

and services through them.

The costs for both the activation and delivery of the service have to be absorbed

by our company (the law currently doesn’t allow billing for the service).

It has been a trend since the 1990s: convert suppliers upstream into de facto

watchdogs on compliance (e.g. on recycling equipment sold to consumers),

extending responsibility across the product or service lifecycle.

The new law includes an automatic draconian measure for non-compliant

suppliers that repeatedly fail to deliver: any existing warranty on any product or

service delivered to consumers is extended automatically by a further 24 months.





A new form of customer service is to become compulsory

Our legal department is exploring the possibility of challenging all the new

requirements at the EU level, as they seem to be disproportionate to the end,

notably when our agents and distributors are non-exclusive.

Considering all these constraints, it has been decided to adopt an approach that

will allow formal compliance at a minimum cost, but, should the new law be

confirmed, enable to expand the service, e.g. to convert the new requirements

into a business opportunity, by increasing the loyalty of both customers and agents

or distributors, as well as providing information useful to reduce the time-to-market

and risks associated with new products and services.

The first assessment on the impacts of the initiatives and how to cope with the

above mentioned constraints and decisions resulted in a list of 18 projects

[reference], involving all the business and support units, not just ICT and HR.





EXECUTIVE SUMMARY/2

Organizational structure and staffing of the initiative

Due to the limited time available, it has been identified as critical the creation of

multiple small teams, each one led by a “subject matter expert” from our existing

operational staff (generally available only part-time, to steer more than manage

each project).

In order to ensure knowledge transfer and smooth delivery of each project, only

internal or external resources that are currently working or worked with our

organization within the last 24 months will be considered.

Furthermore, for some of the projects, it has been identified the potential full-time

use as consultants of recently retired line managers who are still occasionally used

as subject matter experts on organizational, process, and technological changes.

Mr. John Smith has been appointed as the Programme Manager, while Mr. Harold

Wilson from HR and Mr. Andrew Jackson from Finance will be members of the

steering team, under the coordination of Mr. George Patton, the COO, who will be

the programme budget owner.





The timeframe allowed is limited, as the new information service must be fully

operational by January 1st 2016; the deadline for delivery is set at November 1st

2015, to allow monitoring for a couple of months before the deadline.

[In this section a description of the timeline and potential risks/stakeholders would

be discussed, along with budgeting guidelines; in this specific case, usually the

allocation will be focused only on the feasibility study, that will have the mandate

to identify the scenarios and cost options, to enable a further decision]





REQUIREMENTS

The only choice that has already been made (by law) is that we have to deliver

the following access channels, each one associated with a different timeframe:

The new regulation requires that, by year end, we deliver a single access point to

all our distributors, agents, dealers, providing information on changes within

regulations that could affect any part of their operations concerning customers,

including but not limited to sales, service, and withdrawal from market of our

products.

The next page contains a small table listing the projects identified, along with a

short rationale for each one; due to their size, they are named “subprojects”,

allowing the use of the streamlined version of our internal methodology.

Pull on-demand information

Push flash alerts

Updates periodic releases

Training periodic updates

Feed-back collection &

dissemination

Statistical return feed-back to

authorities





1 identify feasibility fact-finding and constraints identification

2a define service

requirements

identify stakeholder needs and SLA/OLA guidelines

2b define service location assess options for location and delivery mode

3a design service design service as per ITIL approach

3b design communication

and pre-emptive marketing

define, design, roadmap communication strategy and

actions/events/media

4a1 prepare service create service components according to prioritization

4a2 prepare service

environment

service delivery logistics and environment definition and

monitoring environment

4b test service with pilot

customer

rolling out the service in customer environment

4c train staff for initial svc train staff for initial service based upon the pilot

4d pre-emptive marketing activate communication elements associated with the pilot

progress

5a coach on-the-job initial

staff

use the pilot results to tune training and coach staff while

carrying out initial delivery

5b monitor at customer site monitoring to both tune and collect progress information

5c marketing campaign

and lead generation

activate communication elements associated with the end

of the pilot phase and lead generation

6 tune service continue tuning the service through the coach on-the-job

phase

7a retrain staff retrain staff based on the results of the tuning phase, and

feed-back from the marketing/lead generation activities

7b acquire further staff acquire new staff while retraining existing one, for scheduled

service roll-out capability readiness

8 transition to Business As

Usual

release project staff (service definition), and structured

knowledge transfer to ensure continuity

9 closing down programme

and thesaurisation

complete knowledge transfer, and assess lessons learned

and potential issues to monitor- plan KPI phase-in/phase-out





CONSTRAINTS

In the previous page, projects surrounded by the blue rectangle are actually

those that could be re-iterated (e.g. if, after the feasibility study, it is identified that

is possible to activate the service gradually and still be compliant).

The target identified during the preliminary assessment is compliance while

minimizing costs, and obviously the projects aren’t necessarily to be carried out as

a sequence, albeit there are some constraints.

Generally, considering the short timescale, this has an impact on the kind of

people that can be assigned to each project.

This obviously dictates for the selection of small teams, each led by a project

manager who de facto acts as “subject matter expert”, and, as such, not

necessarily allocated full-time; team members will be more experienced than in

most of our projects, and external resources will be allowed only if they have

current expertise on our environment.

This programme is to be delivered within a short timeframe, starting by early March

2015 and ending by late October 2015, with a two months “post-release”

monitoring period, in order to ensure that full formal compliance is in place by

January 1st 2016.

The direct impact of this choice is that roughly 1/2 of the time allocated to the

feasibility will be spent on brainstorming sessions





Considering the number of concurrent projects and activities that have been

initially identified, a first feasibility subproject lasting one month is to:

1. Define the overall architecture of the solution, and confirm concurrency

constraints between projects

2. Outline the SLAs/OLAs to be expected, as well as the specific roles and any

further information supplier that should be contacted

3. Activate the initial staffing for the activities

4. Activate the monitoring and reporting system to be used during the

programme

5. Validate the availability and structure of the environment, and/or procure

new equipment and offices if needed

6. Initiate the contract negotiations, be active by the start of the trial phase (i.e.

completed by the end of subproject 3a)

7. Procure the commitment of the appropriate staff and subject matter experts

that are to take on the roles of project manager for each project.

The results of this first feasibility activity have then to be structured within the

subproject 2a, while subproject 2b has to focus on the logistics of service delivery.

The subprojects from 3a on can potentially be repeated in the future to scale up

(expand) or scale down (reduce) the service.

A detailed schedule for the first subproject is provided in the next four pages.





PRJ1: IDENTIFY FEASIBILITY/1

IDENTIFY key requirements to be fulfilled

ASSOCIATE stakeholders, and roles to be assigned

OUTLINE scenarios

COMPARE analysis of scenarios

DECISION on the scenario to be adopted

ANALYSE of the scenario selected, and schedule

BUDGET proposal to be submitted

DECISION on budget and resources

PREPARE resource guidelines and allocation

COMMUNICATE the roadmap to all the stakeholders

During the initial workshop has been identified as critical to devise an approach

that would keep involved, motivated, and informed all the stakeholders (internal

and external) that will be affected by the new compliance requirements, while, at

the same time, keeping at least informed those not directly affected.

Our distribution network will need to be actively involved up to January 1st 2016,

and therefore the assessment phase will have to discuss potential business benefits

not only for our organization, but also our distribution network.

The preliminary assessment that produced this document was carried out through

meetings held in one week-end-long workshop off the premises, involving the

managers in charge of the business units whose operations have been assumed to

be affected.





A detailed list of the material presented by each participant, minutes of the

workshop, and decisions made (positive and negative) is provided within [add

reference].

The identification was based upon an analysis of our value chain, selecting a

“champion” for each phase, as per [insert here reference to organizational design

presentation provided by the Organizational Development office], with a direct

coordination by the COO, as per mandate from the CEO.

[add other relevant summary of key issues identified as constraints by the above

mentioned workshop].

18 projects (i.e. activities that could actually be delivered by separate teams)

have been identified, working across multiple business domains and business units,

therefore during the workshop was agreed that the above mentioned constraints

should be further analysed by a feasibility study. that should provide the results

outlined in the previous page.





PRJ1: IDENTIFY FEASIBILITY/2

Start Activity/Activities Results

20

15

-03

-03

Ass

ess

me

nt

Confirmation of legal requirements

Confirmation of business requirements

Validation of internal constraints

Validation of constraints within our

distribution network (e.g. lack of

Internet or other relevant facilities)

Brainstorming sessions by type of

network membership, with

identification of a “network

representative” to be involved later

on as “programme evangelist”

Brainstorming session with all the

“programme evangelists” and the

assessment team

Summary of the activity

Standards adopted

and communication

plan drafted

Kickstarting and limited

communication done

Scope defined

Target defined

Approach defined

Roles/Activities defined

Milestones defined

20

15

-03-1

6

Sc

en

ario

s

Brainstorming with the Management

Team and approval or changes, with

scenario identification and preliminary

risk/budget assessment (SWOT)

Scenarios analysis

Scenarios comparison

Mapped current vs

target operating model

Assessed delta by BU

SWOT by scenario

Budget by scenario





20

15

-03

-23

Ro

ad

ma

p

Brainstorming with the Management

Team to select the scenario to further

investigate and turn into a roadmap

Roadmap definition

Brainstorming on the roadmap and

approval of the plan

Scenario selected

Roadmap defined

Communication plan

defined

Key roles assigned

Resources by phase

and activity mapped

Constraints and

delivery scheduled

Stakeholders and

communication

mapped

The feasibility study will be carried out in three phases (highlighted the key decision

points), and the next pages

[would contain the following information:

1. the rationale and content of each result

2. the key roles already identified

3. preliminary list of the stakeholders to be involved, by level of involvement

4. preliminary estimate of the activities to be carried out, with details for the

feasibility study, and milestones for the ensuing projects

In this business case, the next few pages contain examples on the adoption of

each one of the tools scenarios discussed within the “Method” chapter]





APPENDIX: TOOLS/1

Option 1: Office Automation

I assume that the audience of this book is from a business environment, and

therefore Microsoft Office is available (at least Word, Excel, Powerpoint).

If that is not the case, OpenOffice can be used, as it is a free OpenSource

alternative that includes also components covering the role of Access, with

Powerpoint replaced by two applications: a drawing application that includes a

limited version of the “smart drawings”, and a pure presentation application.





The Gantt chart that you can see on the left is simply done by inserting as many

columns as you have weeks, and then applying a background; if your spreadsheet

software allows it (e.g. Excel), you can also use “conditional formatting”, so that

whenever a “1” is present, it turns into blue, allowing then to add a column with the

total by row that automatically tells you how many weeks (or days, or months) a

task is long, alter the plan, or add a further row to show what really happened.

Obviously, it is quite primitive, but it can be updated quickly, and, being based on

numeric values, you can add charts (e.g. to compare a “baseline” with actual

results), and use it to monitor the evolution of your resource allocation.

Anyway, if you need a proper Gantt, but do not want to use a specialized tool for

Gantt charts, probably you can find online an “add-on” for your spreadsheet

software that allows to create both a calendar and a Gantt.

From Microsoft Office 2010 on, you can also use “smart drawings” to create the

typical value chain chart, or even a network chart, built just by entering something

as simple as a bullet list with subdivisions.

The concept? The tool allows you to choose a “visual formatting” with a broad list

of options (in most cases, removing the need to acquire a license of Microsoft Visio,

as in my experience 90% of its uses are covered by “smart drawings” in both Office

2010 and 2013).





APPENDIX: TOOLS/2

Option 2: Corporate Standard





Each tool has different strengths and weaknesses, but all share a common

element, the ubiquitous Gantt chart.

Over the years, Microsoft Project added more features- so, you can actually use

Microsoft Project (and its server counterpart) to manage also the “bean counting”

side of project/programme/portfolio management, including by sharing at the

company level a pool of resources, and managing a “skills booking system”.

Frankly, most companies use Microsoft Project just for Gantt charts and little more-

including those that have the server part and Sharepoint (and sometimes add

Clarity too).

The main weaknesses of Microsoft Project (it isn’t workflow-based, and therefore

supporting “stage-based” project management approaches can be a nightmare,

and doesn’t manage a document repository) are overcome if you, with or without

the server part of Project, use also Sharepoint and its “workflow management”

abilities.

The main drawback of a “full Monty” solution involving Project, Project Server,

Sharepoint? You need deep pockets to buy the licenses, and deeper pockets to

create an integrated solution that runs smoothly and is able to withstand the

attempts of users to bypass controls or be “creative number crunchers”.





APPENDIX: TOOLS/3

Option 3: Workflow-based

Actually, ProjectInABox is a tool composed of two tools, a planner (and risk

tracking) tool, and a workflow-based document management tool (available also

as an integrated, corporate-wide messaging and document repository).

If your company has a methodology, you might appreciate few characteristics: it

comes with a set of pre-defined methodologies; if you buy the lowest priced

version upgrade you can modify existing ones or create new ones; and it is a

scalable solution (both in terms of features, integration on a team or corporate

scale, and methodology add-ons).





I used it only for one reason: I was looking for a project management tool that

supported the programme management counterpart of PRINCE2, MSP, and this

was the only tool available.

Then, while I dislike some issues within the “planner” component, I like the ability to

see planning not just in term of human resources, costs, or time, but also of risks

(including by quantifying impacts).

Actually, in some cases I would skip using the planner to produce the Gantt, and

focus instead of mapping out and costing risks and their impacts (a boring task, if

you do it in Excel).

At the same time, if you do not have an internal methodology, the “support of

methodologies” I referred to is something more than just providing stages:

ProjectInABox contains, for each methodology, a graphical workflow, support

documentation (e.g. for Agile on DSDM, for MSP, and for PRINCE2 or ITIL), and

templates for each phase, so that it can be used also as a learning platform to

ensure consistency and self-learning across any organization whose

project/activity managers have a high turnover rate.

The Community Edition of ProjectInABox is free (you just need to register), and

works under Windows.





APPENDIX: TOOLS/4

Option 4: Web-based

Over the last decade, another category of project management tools gained

traction: software tools based exclusively on the Web (or SaaS/PaaS, in “business IT

lingo”).





I used a few in the past, and even recently I resumed trying one, but for this

comparative test I selected an OpenSource option that I used a decade ago to

manage a concurrent pipeline of start-up projects (basically, from lead

qualification to business&marketing planning and management coaching).

dotProject is still available online (it requires a server with a database such as

MySQL, plus PHP), and can be easily modified and extended.

Nonetheless, it showcases features that should be available in any Web-based

project management tool, ranging from the possibility of integration with business

processes (e.g. invoicing, HR, email), to an internal messaging system, to

document warehousing by task/project/etc., to a feature that I used extensively in

the past: the possibility to attach a forum globally, by customer, or by project

(more about this in a future episode).

As you can see, a Gantt chart is a Gantt chart, and dotProject on that side

contains standard features (e.g. adding information about people, costs), plus a

quite flexible (albeit sometimes faulty- hence, my half-hearted support of it as a

corporate choice) access control system: you can allow users to do anything or

nothing, and on any information- down to no information at all (try managing that

with more than few dozen users- you would need an administrator).

Web based solutions usually have a freemium business model, i.e. basic services for

free, everything else for a monthly or yearly fee, with “packages” by project,

customer, or role/feature combinations.





CHANGE AND COMPLIANCE

As outlined within the introduction, the case study is a compliance mini-

programme to be delivered within a really short timeframe: 18 projects in less than

8 months.

It is not just consistency that matters, but also how you cope with and recover with

unavoidable mistakes or “failures to comply”- “giving a second chance” is part of

this specific corporate culture.

Even for an initiative as short as the one outlined within this business case it is

advisable to have a preliminary “fact finding” before planning starts, a preliminary

“data collection”- about both what is required by the new law, and what is

already available within the organization, so that then a proper feasibility study

can be carried out.

In many organizations, “hitting the ground running” is considered the way to go:

and I will let you have a look at books on WWII events on what happens when you

drop paratroopers without first doing a proper fact-finding.

Business in most cases is more forgiving, but the less time you have, the higher the

potential impacts of any misstep, and the less you have excuses to skip a feasibility

study before committing resources based just on a “guesstimate”.

Therefore, I have always been puzzled by how organizations with less resources to

waste “save” by doing without feasibility and/or analysis, as if both were something

worth doing only if you are a mega-corporation.





SCOPE & PLANNING

A first obvious step should be to identify the requirements embedded within the

new compliance requirements, and then assessing potential impacts by involving

relevant business units and operational staff (more than managers).

The fastest approach that I saw working in practical cases was to prepare a

“position paper” to be shared before a brainstorming involving those that could

contribute to definition of the roadmap.

Scope definition is still a business choice, but it should be based on a clear

assessment of potential impacts and risks/opportunities- it isn’t a matter of taste.

In a compliance case, there is an added “bonus”: as you know the “due by” date,

the activities identified can be distributed by starting from the end, with a “safety

margin” left between the due date and the end of the activities, and whatever is

identified as belonging to the scope is to be distributed across time accordingly.

Therefore, it often starts with a rough Gantt chart built around milestones- (see next

page) and the only resources identified from the beginning are those that will lead

the effort.





MAPPING THE TERRITORY

In this business case, it might seem disproportionate to spend 1/8th of the time

available on planning and outlining, but in reality this is often the case, as that

month delivers what is actually, for similar activities, closer to a “business blueprint

and resources+deliverables shopping list”, so that a business choice can be made.

Typically, this isn’t delivered as a single sequence of activities, but with three main

phases:

1. Data collection (internal and external), and confirmation of guideline

2. Scenarios identification based upon the guidelines

3. Analysis and “roadmap for delivery” of the selected scenario.

Furthermore, you can then potentially identify areas where the timeline can be

“compressed”, e.g. by having teams working in parallel, and maybe then adding

steps to integrate and collate the results produced by each team (consider the

case of a complex business proposal: would you have just one team working for six

months sequentially?).

Obviously, you have first to identify what can be split between teams.

1 2a

2b

3a 4a1

4a2 4b

4c 5a

5b 6 7a 8 9

7b 3b 4d 5c





Decades ago it started on a

corkboard with pins and bits of

paper shuffled around.

Then evolved into a whiteboard

with PostIt™ notes), albeit if you

think visually, any tool allowing to

freely shuttle shapes around is

useful- including Powerpoint.

For the Powerpoint enthusiasts out

there: it is less than perfect, but

easier to maintain if you use

extensively “SmartArt” drawings for

your charts.

I use a "Mindmap" tool called

Xmind (again, a freemium, working

on various platforms)1.

THE PROJECTS

1 identify feasibility

2a define service requirements

2b define service location

3a design service

3b design communication/pre-emptive mktg

4a1 prepare service

4a2 prepare service environment

4b test service with pilot customer

4c train staff for initial service

4d pre-emptive marketing

5a coach on-the-job initial staff

5b monitor from customer side

5c marketing campaign&lead generation

6 tune service

7a retrain staff

7b acquire further staff

8 transition to Business As Usual

9 closing down programme&thesaurisation

1 A huge online library of maps from other users might actually save you some analysis time; see

http://www.xmind.net/share/aleph123/ for maps that I posted since 2009



http://www.xmind.net/share/aleph123/



GANTT, CPM, AND PERT

Our society is quite complex- but, eventually, tools developed by a “niche” of

specialists surface within mass media, and become common parlance.

Any activity involving more people and organizations requires a form of planning

and resource allocation, ranging from a mere agreement on who/what/when, to

more complex arrangements (e.g. conditions associated to what can be done

when and by whom).

Gantt charts were originally created to support production planning (we are used

to look at the width of a bar, but it used to be relevant also its height, and could

carry around other information on the resources used by the activities).

If you were born in the 1970s, since you started reading newspapers and

magazines you got used to see how activities evolve, presented with a form of

Gantt chart; so, you don’t need to be a project manager to be able to read one.

It might be because your local community has to deliver new roads, or just for the

plan leading to next Olympic Games, or (I hold an Italian passport, hence…) the

schedule for the next European Football cup (soccer, for my American readers):

they are all variants of a Gantt.

A Gantt (see examples within the “Appendix: Tools” of the “Business Case”

chapter) is nothing more than a (usually) vertical list of activities, whose delivery

across time is marked by a sign in columns representing time.





For the more technically oriented (in planning, not ICT, terms), the link between

two bars can be somewhat more complex than a mere “first A, then B”, but overall

what a Gantt shows nowadays is a sequence of activities- within a project, or

across multiple projects, with some constraints (e.g. when, in relation to A, B can or

has to start/finish).

In the late 1980s, before Microsoft Project, I used other tools that were specialized,

e.g. producing just the Gantt chart, or producing a variant that allowed to identify

the “critical path”, or a more modern chart, PERT, created in the 1950s for complex

activities involving a myriad of projects and, as in the business case outlined here,

projects of a different sort.

When you have a relatively complex Gantt, eventually there might be activities

that overlap, and therefore require more resources to be available at the same

time, and activities that, if delayed, could wreak havoc on your wonderful plan.

A typical example is contained within the business case: you can train people to

deliver a service, but if the building (with the appropriate equipment) required to

deliver that service isn’t ready by when they will have been trained, they will just sit

idle.





PERT: INTRODUCTION

Early

start

Duration Early

finish

4 6.33 10.33

Task name Task name

Late

start

Slack Late

finish

8.68 4.68 15.01

In a complex project, sometimes there is a “backbone” of activities that have zero

or limited flexibility- keep track of the cascading impacts of any change.

No matter how good are the teams focused on other activities, the most critical

activities are those that could make all those efforts useless.

In a nutshell, this is what the “critical path method” is about- and I used software

being able to do just a Gantt and a CPM analysis decades ago (less visually

appealing than what you have now, but still useful).

A PERT diagram (shown above) can be useful in even more complex cases, and it

is filled in two steps (from beginning to end, and from end to the beginning), and

involves some statistical number crunching (the example is from Wikipedia).

It isn’t just a chart, it more a “technique” (it stands for Program Evaluation Review

Technique), and it is more or less a contemporary of the CPM.

The computations? 10.33 = 6.33 (duration) + 4 (early start); 15.01 = 6.33 (duration) +

4 (early start)+ 4.68 (slack)





Personally, after drafting a Gantt (more easily understood by non-

project/programme managers), and maybe using the CPM-equivalent within

Microsoft Project or other tools to “highlight” visually which activities, subprojects, or

projects are “critical”, whenever feasible I prefer to keep track by using a “macro-

level” PERT or at least a network chart, to allow the coordination of multiple

activities by immediately showing, quantitatively, how things are evolving.

If you read any book on project management that presents Gantt, CPM, PERT, you

will find reference to “tasks”, but actually if you work at a macro-level you can still

find them useful, as a “roadmap management tool”.

In this business case, it is even more probable, as some of the (sub)projects might

not have their own Gantt.

If you have an activity lasting two weeks and having a “standard” sequence of

tasks, using a Gantt instead of a plain sequence in Excel is often a sign that

whoever was assigned to it is “green” enough to put the tool before the aim.

A Gantt can be useful while planning, but a “tracking Gantt” (i.e. showing where

you are) and a CPM allow you to monitor and identify areas worth of intervention,

while a PERT allows you to continuously assess “how much” flexibility is left within

your schedule, so that maybe you can find expedient to postpone some non-

critical tasks and re-allocate temporarily people to tasks that require more

resources (if it makes sense to add resources- sometimes, it is just a waste, as it adds

then the need for further oversight or integration).





http://www.twitter.com/robertolofaro


EPISODES SCHEDULE

#QuPlan - A Quantum of Planning - Episode 2015/0 - Business Case and Product Comparison

Documents

Transcript of #QuPlan - A Quantum of Planning - Episode 2015/0 - Business Case and Product Comparison