In the first article of this series I look at the maths and formulas relevant to the SCOPE of a project.
The review will not be exhaustive, but just an attempt to signpost some of the math’s fundamentals and formulas which can be used in activities connected to this aspect of a project.
Under the term SCOPE I here intend the product scope, as the “features and functions that characterise the output from a project, as a product, service or results” and the project scope, as “the work performed to deliver the project’s output“. I cover the subject under three topics:
- Utility & Impact
- Risks & Change
- Complexity.
I hope you find the article interesting!
Utility & Impact
What is the project intended to achieve? What are the benefits that the project is intended to deliver? What is the extent of change that the project should bring?
Much here depends on the sector or field in which the project operates (engineering, service provision, R&D, marketing, etc). It is likely that there will be some financial indicators used to qualify and quantify the desired outcome. There will also be some “proxy” indicators for the benefits. There will be measures and metrics that will form the basis for operational, tactical and strategic KPIs, and also impact KPIs that will help in monitoring the progression with the project activities. Calculations will be specific for the project.
For each project there will be the need to define a “baseline” for the market, the product or the service and the project will be targeted to improve over that baseline (improved market reach, greater geographical spread, more customers, greater revenues, improvement of conditions, status or service level, etc). Aside from the more traditional ROI and financial KPIs, if you have an interest in non-profit project performance you may want to check this link , providing interesting examples of Outcome Indicators. You may also check the Social Return of Investment (SROI) or the Disability-Adjusted Life Years (DALY) for social and public health interventions.
For each project there will be a build-up of data to provide the justification for the project to be sponsored, funded and undertaken. It is likely that some Descriptive Statistics will be required, used to summarise the sample data available. Descriptive statistics helps describe and understand the features of a specific data set by giving short summaries about the sample and measures of the data. Think about mean, median, mode, standard deviation and range as measures of tendency and spread in the data.
Inferential Statistics will then allow us to draw conclusions about populations by using small samples. The most common methodologies used are hypothesis tests (T-tests) and analysis of variance (ANOVA). You will have to check a statistics book or consult a statistician here, as I am not qualified to go any further.
The maths above is likely to be required to assist in the preparation of the necessary case for the project to go ahead.
Risks & Change
What are the key risks? How is the project progressing? What corrective measure to introduce?
There is a lot happening in the course of a project. Change is always looming. We know that most of the projects these days are more “adaptive” than “predictive”.
All projects will have specific mechanisms and tools to monitor key performances over time and Time Series will be probably used. The Time Series is a forecasting method used in statistics, signal processing, econometrics, performance management or mathematical finance. It is the use of a model to forecast future events based on known past events, to predict data points before they are measured. These time series, together with risk management, help in addressing needs for future changes.
Probability theory is a branch of mathematics concerned with the analysis of random phenomena and it has an important application to project risk management. The management of probability distribution is quite complex and sometimes the use of the various types of distributions is limited to specific sectors and for mega-projects. There might be an interest in dipping into the Monte Carlo simulation (link).
With abundance of data, access to historical measures and other parameters’ datasets, the use of Correlation Analysis is relevant. It is about measuring the “strength” of the linear relationship between two variables and computing their association. In simple words, correlation analysis calculates the level of change in one variable due to the change in the other. This analysis may help in identifying the absence or presence of a relationship between two variables or a direction and strength of the relationship between two variables. Think about checking correlation in past projects for the effectiveness of a marketing campaign and the success with specific interventions that could help with directing future corrections in the current project.
The Hypothesis Testing is important in the course of the project. Based on evidence provided with samples of data collected, a hypothesis test is a rule that specifies whether to accept or reject a claim about a population depending on the evidence provided. Think, for example, of sales data collected after a specific intervention in the advertising campaign, with a test to see if there is a difference compared to pre-correction. The “null” hypothesis is a statement of “no effect” or “no difference” and the test examines this against the “alternative” hypothesis (i.e. there is a difference). Project professionals should be familiar with the approach although some assistance will be required in setting up tests correctly.
I end this section with something very interesting, the Decision Matrices. They may be called with many other names, such as Pugh matrices, decision grids, problem selection matrixes or criteria-based matrices. A decision matrix is often used when a list of options must be narrowed to one choice using several criteria and where the number of options is of a manageable quantity. It may sound very simple, but it should be structured properly (see the Analytic Hierarchy Process, as an example), especially if weighing criteria are to be introduced or when the approach must be “defended” in discussion with management, project sponsors or auditors.
Complexity
In one way or another complexity will appear on every management agenda.
In the project portfolio the top priority projects may not be simply those with a high budget. There could be projects down in the rank which could require particular attention as very critical, for example, to reputation.
Complexity Analysis is, to an extent, a spin-off of the Analytical Hierarchy Process mentioned earlier. Projects will be ranked according to specific criteria. It could be just three simple attributes, like Technology, Operations and Environment, but the ranking can be more complex.
In this example, for IT technologies projects, a list of 10 attributes is proposed: Objectives, Interested parties, Cultural and social, Innovation, Project structure, Project organisation, Leadership, Resources and finance, Risks and PM methods. In a separate article there has been a mention of an interesting simple formula, as:
Complexity = (Communication Channels + Roles Complexity) x Stress.
The above may be peculiar to IT projects, but in all sectors there is a greater interest in the handling of various big data sets, their interconnection and inter-relationships, with the attempt to model and address complexity. This is probably an area of development in the maths applied to project management.
What about Agile projects?
Similar principles will apply in establishing impact and utility for Agile projects. A baseline will have to be established in order to determine the impact that the project will have. The maths should be similar for all types of projects (I hope I am right in saying this!).
I would welcome feedback from those readers who have more experience with Agile.
In this article I provided an overview of the maths and formulas that in my opinion would help in the project SCOPE definition and control. In the next article I am venturing into TIME and schedule. Please do not hesitate to contact me for any comments and constructive feedback.
Marco Bottacini, Senior Portfolio Manager, GALVmed
The views and opinions expressed in this blog are those of the author and do not necessarily reflect the views and opinion of GALVmed.
Project Management Discussion Group 