Talk of PPM, PMO and All Things Project

Welcome to this blog!

I hope to provide you with informational nuggets from my learnings and the successes/failures I have had in all things 'project'. I have worked across many industries and many cultures/countries, so most of my summarizations can be considered 'universal'.

Please send me an email if you have any special area of interest that you would like me to write on. If I can I will, if not, I will research and promise to send someone your way who can be of help.

Wednesday, September 14, 2016

In a data-rich world how do you become meaningfully data-centric?

There is no shortage of data in today’s inter-connected world. Companies have recognized this for a while now and have invested significantly in capturing, mining and reporting on this data. But are they satisfied with what they are seeing? The answer is a resounding NO. And why is that? Because of two insidious human elements. One is the quest to identify or extract truly meaningful data and the other is  to create an organizational structure that explicitly addresses the need to be data-driven. I will examine both of these in an attempt to suggest more meaningful and methodical changes vis-à-vis data and its vast horsepower.
Data, data everywhere but not a drop of meaning!
Data has the ubiquitous quality of appearing ‘official’ and ‘meaningful’ in whatever context it is presented. Intuitively we know that this is not correct. For example, just because there are data points which are taken at earlier and later points in time, it does not mean we can derive cause and effect relationships between them. In fact, where incorrect or meaningless correlations are made, the result is detrimental to ‘right action at the right time’ and are difficult to challenge. It is my submission, therefore, that experts such as social scientists for social media data/big data, financial specialists for financial data etc be employed to interpret and put intelligence to the data. It is important to note that this requires processes to allow these experts to derive meaning only from data relevant to their area of expertise and prevent them from having a massive lateral view of all data. Yes, data restriction is vital. In order to provide a wide enough view of data to the specialists that allows them to keep the ‘bigger picture’ in mind and narrow enough to not cloud their view, it is necessary to involve them in the design and deployment of all stages of data processing – collection, storage, mining, reporting.
Creating a culture of data
Companies have been oscillating between being numbers driven and gut-feel as they experience the phenomenon of meaningless or misleading statistics/data points and the instinctive need to be objective. In order to promote a culture that is truly acting on intelligent data the following data related roles are recommended:
1.       Chief Data Officer: The role must report up to the highest level in order to make deep changes. The person must use a top-down approach starting with strategic measurement areas and mapping these progressively down the food-chain to establish KPIs and reporting needs for each department/function
2.       Data Analyst: The role must be a data management expert with knowledge in data modeling, database design, ETL principles, data analytics principles. This role should operate at the division or function level to help decompose the tier 2 KPIs and reporting needs in line with strategic needs defined by the CDO. Data Analysts should report up to the CDO
3.       Data Specialist(SME): The role is the expert defined in the section above. They are Subject Matter Experts in a field such as Social Science, Accounting, Marketing, Finance etc. They are NOT data analysts. Rather, they are folks who know their subject area and can interpret data to draw meaningful conclusions and avoid spurious correlations. They are also the 'seekers' of relevant data and determinants of which data is relevant and which data is not given a specific area of analysis. This role should work with Data Analyst to create a full map of source and destination of data (destination could be reports or corrective action). Data Specialists should report up to the functional or departmental heads and have dotted line reporting to CDO’s office in partnership with Data Analyst. Some of these Specialists will be function-specific (such as social scientist for big data) and some will be department focused (such as Marketing).
4.      Data Process Specialist: With function and department heads and in collaboration with Data Analysts, this role will define the nature of reporting, processes for corrective/proactive action and police compliance with data-driven communications and reporting throughout the organization. This role can have the role of evangelizing the CDO's mandate of driving processes based on objective interpretation of data.
Finally, a word on a current data-related role in many organizations - the Data Scientist. Their job function varies from one company to another and is a mish-mash of two or more of the roles described above. It is important to note that Analyst, SME, and Process Specialist are three distinct areas of expertise and rolling their functions into one title "Scientist" is short-changing the effort to create a data-driven culture.

Monday, April 9, 2012

What’s in a Name? Everything! The Three Types of PMOs

We are here for discussing, dissecting, deliberating and defining everything about PMO’s, right? But wait! What TYPE of PMO are we talking about. Unfortunately there are three key words here that all start with P – Project, Portfolio and Program. So a PMO could be a Project Management Office, a Portfolio Management Office or a Program Management Office! (Or any hybrid in between). The functions, scope/reach, mission and staffing are very different in each as it should be.

I am not sure if there is a clear distinction that the industry has made between these offices. This article is about to do that in a succinct way. But first, let us distinguish as to what each of these functions are. To do this, let us borrow from PMI’s definitions. A project is a piece of work with a definite start and finish. A portfolio is a set of unrelated projects which have some sort of umbrella management over them such as budgeting.  And finally, a program is a set of related projects.

What is common to all three types of PMOs  is that they are responsible for doing certain functions consistently, and they have established/accepted tools and techniques to do them with. What is not common to them, is the content of the functions, where they belong in an organization and the skills needed to staff and manage them successfully.

Project Management Office
Portfolio Management Office
Program Management Office
·      Establish common project management principles
·      Define standard tools and templates
·      Oversee consistent application of enunciated project management principles and tools/techniques
·    Provide Business case justification for projects
·    Provide budgetary analysis and support for all projects across the spectrum
·    Monitor and control purse strings
·    Provide fiscal analysis before and after execution
·        Establish cross-project oversight methodology. Tools and templates
·        Provide cross-project dependency management
·        Oversee consistent application of cross project methodology, tools/techniques
Where it sits
·     Within a group or department
·     Typically used by IT groups
·  A front gate performing entry functions for projects entering the group, the department, or  the enterprise
·  Typically at the enterprise level
·  Could span multiple departments (such as a geographical locations) if not at the enterprise level
Methodology & tools/templates creation
·       Bottoms-up
·       Chosen from best practices
·  Enterprise or C-level mandated
·  Created after enunciation of PMO mission
·  Tools/techniques established at the start of the PMO
·  Methodology many not exist or may not be rigid
·  More opaque to day-to-day project execution and management
·  Enterprise or unit level
·  Created after enunciation of PMO  mission
·  Methodology created and evangelized early
·  Tools/techniques and tailoring guidelines established at the start of the pMO
·  Control and monitoring evident in day-to-day project management
·       Senior Project Management Practitioners
·       Financial and staff management professionals
·       Business Analysts
·       Program Management Professionals

Tuesday, October 4, 2011

What level of formalization is an absolute must for a PMO Methodology to be successful beyond which it becomes just bureaucratic paper pushing?

Implicit to this question is the understanding of what is a methodology and what is the limit at which ‘bureaucratic paper pushing’ begins. In order to begin I am adapting from David Christiansen in
A process is an instruction book, the step-by-step kind that come with a child’s bicycle or a new VCR”.
“A methodology adds in a box of tools to the process by specifying at what stage/step of the process which tool can/should/must be used..

With this understanding it is evident that ‘bureaucratic paper pushing” can occur if the methodology is too rigid (you MUST use this tool at this step)  AND/OR the process is too rigid (you MUST do Step X before you do Step Y even though your project/program can do with out Step X).
First, methodology – when does it become inffective?
i)                    When a PMO is not cognizant of the number of tools it is putting in the box
ii)                   When it is not specific and explicit of its statements of the circumstances under which a tool is to be used or not used
iii)                 When there are too many overlaps in the tools and/or there are too many variations of the tools – each  made specifically to help in a very narrow/rigid scenario
iv)                 When there are prescribed tools for (almost) every step  which fall in the MUST USE category
v)                  When there is not enough guidance built into the process to allow tailoring such that the methodology used is apt and agile

Next, process – when is it ineffectual bureaucracy?
i)                    When a PMO process is too onerous reducing Project Manager to only manage to checklists
ii)                   When creativity is stifled in the name of standardization – there is little to no room to tailor
iii)                 When agility is seen as the antithesis of formality/rigor in management of projects

Paradoxically, these issues cannot be answered head-on, the real answer is …”it depends”. The factors which dictate the size of the toolbox, the variations of the tools in the box and the level of rigidity of the process depend on
a)      whether the PMO has to interface with external entities such as regulatory bodies or external stakeholders
b)      whether there are legal, actuarial or statutory implications of the projects under the purview of the PMO
c)      how large is the ‘common ground’ that the PMO covers where it is beneficial to  create a standard/repeatable process for executing projects/programs

All these questions should be tabled, and agreed upon in a charter before the mandate of the PMO and its advocated methodology is drawn up.

Thursday, July 7, 2011

Improving Software Robustness

If  the software industry were the automobile industry or any other manufacturing for that matter, it would have declared itself unviable and shut down by now. Why is it that 70 years after the industry began, it continues to churn out ‘defective’ products? Granted, we have made strides in delivering products which are ‘correct’ or ‘defect-free’ within the functionality conceived for them, but all too often we find this functionality is limited, incorrect or hopelessly misguided.
In other words, there seems to be no way out. Here is  a car analogy. Consider that the world has seen boats and ships but never seen automobiles. For us (aka the software industry) to deliver a roadworthy/safe car to drivers instead of giving them motorized boats which can be treated as automobiles by attaching wheels to their bottom seems to be a project we are completely unable to deliver.

Wrong. We can. We can deliver a roadworthy car - we can conceive of it, design it and produce it even though we have never seen it before now.

Recall the V-Model for software testing
(Picture acknowledgement :
The broad idea of the V-model is that when test plans are made in parallel with the early/inception phases of a project, the testing tends to be more comprehensive and the ability to design better tests becomes more acute.
In reality, test planning rarely begins at the Concept of Operation phase. And even if it does  begin that early in the process, the end users who SHOULD have the ultimate say are rarely represented here. Instead, a planning/strategy board tables the idea(s) which get incorporated into project charter(s) which then form the foundation of the ultimate product that is delivered.  Whether this product is really what the end users want/like is hardly ever considered. Often it is argued that asking end users at this point is useless since this is the stage of ‘big picture’ and ‘idea generation’ seen from ’50,000 feet’. I argue that the proof of the pudding is in the eating. The left side of the V should NOT be a top down process only. Concept of Operation should begin with a  data collection exercise with terminal end users.
Consider the following: You have decided that the software used by your chain of pharmacies to track and remind patients when their next refill is due will need an upgrade. Do you begin by asking the average patient/consumer what they would like to see in this upgraded system? NEVER. I submit that this answer should be - ALWAYS. The way to go about is to hold focus groups with statistically random samples of consumers in much the same way as marketing folks do to get product improvement or new product ideas. The focus groups should question them on the good and bad of the current system and where they would like to see improvements. Use established focus group moderation techniques to arrive at potential areas of improvement in feature/functionalities, processes and/or interfaces. Use this as the basis for forming new Concepts of Oepration.     
Consider the following for another rationale for why this is a robust idea:
The software industry has definitely improved in the past two decades in reducing errors (aka  ‘bugs’) through rigorous implementation of principles such as TQM. So even though systems no longer crash unexpectedly with mind-numbing frequency, end users continue to experience gaps, disappointments and process breakages with systems. The reason for this is clear – the requirements were prescribed by an end-user representative/group who have their own limited perspective of the business case – thus while the testing is full and complete nowadays, the system itself is far from being ‘full & complete’ from a cusomer expectation view-point. Step in focus groups a la market research style and we will be well on our way to stepping up in the maturation of the industry.

Thursday, April 7, 2011

Communicating Project Plans with rookie teams

An increasing number of companies are beginning to realize the value of undertaking ALL their project work through a tried and tested repeatable process - i.e. use methods, tools and templates advocated/supplied by a PMO. For this reason, project managers from PMO's are being seconded more and more into non-IT groups which typically have very little or no project management experience.

To a seasoned project manager, who has dealt with numerous Microsoft Project Plans, phrases such as "predecessor task", " resource leveling", or "float" are par for course. Not so with teams unused to running projects with PM tools and methods. So the loaned out Project Manager has to be extra careful not to overwhelm and turn off the team, because not only must s/he produce on-time results, but also because the PM is an ambassador of the PMO methods, tools and templates to the larger organization.

So here are a few tips on how to communicate better with the project team specific to project plan items which are typically the meat of  project team communications: dates, milestones, critical path etc.

1. Never show the entire plan to the team - especially in the early stages of the project when all the dates are not finalized. Seeing default start and end dates puts people off track when they do not have a "filter" in their minds about recognizing and ignoring those dates.

2. Create text columns which will help you filter out tasks - such as department name. So if you need to provide dates to that particular department for all the tasks they are responsible for, you can do that easily.

3. Always filter the plan to show relevant tasks: some common ones would be
 (a) resource name
 (b) a particular keyword in the tasks themselves
 (c) a certain end date
 (d) upcoming tasks for the next one week or one month.

4. Always show only the milestone report to stakeholders who are not operationally involved in the project.

5. Create Word or Excel Reports for decision makers based on the plan if there are resource or critical path issues. Never use Microsoft’s Reports to explain the ‘issues’ you are seeing.

6. If there are multiple individuals on the project team from different groups, departments, or divisions it is important to figure out their history of how well they work together. If the team is large or there is some history of delays in projects involving one or more of these groups, try to hold team meetings with each stakeholder group separately, once the project plan has become stable or has been baselined. Communicate dependencies between the groups through a separate tracking document/mechanism. This is because unsavvy project teams tend to “storm” for  much longer and in some cases never reach the “norming” phase. So the less they are exposed to tasks of others in an uncontrolled way the less difficult it gets to produce clear messages.

Thursday, March 10, 2011

PMO's Role in Project Inception

The days of kicking off projects after some senior level discussions and some paperwork with the finance guys to allocate funds is becoming increasingly rare. For the most part, the days when a 'sponsor' expressed desire for a particular outcome, coupled with some paper allocation of funds which almost never got tracked against actuals, is over. That is not to say it does not happen; but factors such as increasing awareness of the high probability of project failure, leaner times and internet speed of adaptation have all demanded a greater degree of 'science' in the conception, definition and inception of projects.
While many organizations have incorporated a formalization of these activities through some documented process, most commonly this has come to be housed in the PMO function. The virtue of doing this is obvious - the 'pre-' and 'post-' factors can be articulated and analyzed in the same place so that the organization can do projects cheaper, faster, smarter. So what specifically does a PMO need to do for cheaper, faster, smarter, more business appropriate projects? I submit these are 6-fold:
1. WHY - Articulate the project's charter, what goals it seeks to achieve, what the business objectives of the project are
2. HOW - Enunciate the measures for its success i.e. how the project's end-result  will be measured: these are usually in terms of cost/time savings, market share increase, profitability increase or other measurable success factors
3. WHO will do the project , who is affected, who will make decisions, who will fund
4. WHERE will it be done and where it will have impact i.e. geographies, business units, customer types etc
5. WHEN - The time it will take to  complete the project, when it will be operational
6. WHAT - the scope of the work
While most of these may seem intuitive, you will be surprised how many projects lack clear definition on some or all of these 6 aspects rendering them either failed or at best unknown/unquantifiable in terms of their end-value in which case it is impossible to justify the cost/benefit of the project.

What often happens is that the sponsor is in a hurry to get the work started, and without a formal PMO to contend with may be tempted to or unconsciously bypass these critical efforts. It is the job of the PMO to ensure that it has enough executive level support to stand in the way of shortcuts and quick launches in favor of a more rationalized approach. Having said that, it is also the responsibility of the PMO to ensure that the process is not so lengthy and/or cumbersome that business/sponsors have real gripes about the value of the exercise. Most of all, PMO's need to close the circle of the project by doing a post- mortem on the business benefit of the project in addition to a post-mortem of the project execution itself and ensure that the benefits & lessons learned are communicated to all stakeholders in a timely fashion.

Finally, the PMO has a critical role to play in reporting back the financial performance of the project and eventually have ties into the business unit to see to the financial viability of the end-product’s throughout its life. This way, the PMO becomes an important stakeholder in also proposing the inception of new projects.

Monday, March 7, 2011

Can An Experienced Project Manager Be a Good PMO Manager?

The art and science of starting, manning and running PMOs is a relatively recent phenomenon. And just like any other ‘new’ discipline, there are two simultaneous well-springs developing: one is the rush of towards PMO Management by individuals, hiring experts and headhunters who have Project Management skills or know others who do. The other is a steady maturation of the typically desirable profile of individuals who  have grown through the ranks of  Project Management.

Regardless of the origin of one’s claim to PMO Management skills, all concerned should be well aware that PMO Management requires job skills which are not all readily attained from traditional project management. There are three main factors influencing how much of one’s project management experience can be transported to PMO management:
(a)    the level of project management that the subject was involved in – in their organization (junior versus senior/wider role)
(b)   the level of complexity that the projects themselves – usually one’s ability to understand, utilize and refine oversight and management of process areas, knowledge areas and phases depends on how ‘quick and dirty’ one’s project experience has been
(c)    the project management maturity of the company one has worked in – is there a good understanding of the role of checklists, templates, documented processes, tollgates etc.

Experience needs to be complemented by some degree of formal introduction to PMO Management which, while it deals with the traditional knowledge areas, it does so on a wider scope, in-between projects and with much sharper focus/alignment to business results.

The level of understanding or education needed depends as much on the background of the person’s experience as it does on the mandates of the PMO – whether it is an Enterprise Level PMO or pertaining or one department or Business Unit, whether it is doing Program Management, Portfolio Management or simply more streamlined Project Management.

The following is a ready cheat-sheet of the essential role difference that headhunters, hiring companies and individuals seeking to make the shift can refer to:  
Write Charter
Responsible, Consultative
Project Level: Responsible
Program Level: Responsible, Consultattive, Informational
Business case documentation
Responsible, Consultative, Informational
Risks documentation
At project level after kick-off and during monitoring & control
At program level prior to inception and updated based on environmental changes
Stakeholder communications
External Dependency Management
Vendor Management
Responsible, Accountable
Quality Management
Responsible, Accountable
Process Management
Plan, Enforce
Plan, Accountable
Lessons Learned & Best Practices
Ensure utilization
Human Resource Management
Responsible, Accountable
Schedule Control
Responsible, Accountable
Cost Control
Consultative, Informational
Budget control
Responsible, Accountable
Responsible, Accountable
Informational, Consultative