By Ramiro Rodrigues
A good definition of the word “maturity” is the state of people or things that have reached full development.
For entities such as business organizations, maturity needs to be associated with a specific expertise. This can apply to operational, technical and also project management maturity.
Project management maturity means that an organization is conditioned to evolve qualitatively in order to increase the chances for project success.
To this end, there are both paid and free maturity evaluation models on the market. The application of one of these models allows you to achieve the first important objective: identifying what stage your organization is at.
This step is difficult, given the complexity in trying to compare whether an organization is doing its projects well in relation to others, without being contaminated by individual and subjective perceptions. Often, most models will question various aspects of how projects are executed and produce a score for ranking. With this result, the models will classify the organization's current maturity level.
Once this level has been identified, the next step is to try to plot an action plan to move to the next level. Here is another benefit of a good maturity model: Many offer references to the most common characteristics expected in each level. With this, it is easier to draw up a plan of action focused on the characteristics expected at the next level. This progress should be incremental—one level at a time.
The action plan should be thought of and executed as if it were a project, following the good practices and methodology of the organization itself. It should be scaled to be completed in time to allow its gains to be observable and perceived by the organization. This will then cause the expected positive impacts in the next cycle of a new maturity survey.
In summary, the steps to be followed are:
1. Apply a maturity search.
2. Evaluate and disseminate the results of the first survey.
3. Develop an action plan.
4. Rotate the project to the evolution of the level.
5. Go back to step one and continuously improve.
By following this sequence, you can foster a constructive cycle in your organization as you continue to evolve your ability to execute projects.
I’d love to hear from you: Have you used maturity models in your organization?
By Lynda Bourne
As you may know, any monitoring and control process has three components. The first is establishing a baseline that you plan to achieve, the second is comparing actual progress to the plan to see if there are any differences, and the third is taking corrective or preventative action. Corrective actions fix existing problems, while preventative actions stop problems from occurring in the future.
This post looks at the middle phase. Before taking action to bring performance into alignment with the plan, make sure the variance you are seeing in the control systems is real. Corrective and preventative actions take time and usually involve costs, and there is no point in expending effort where it is not needed.
The variance is the difference between two imprecise elements: the planned state and the actual situation. The plan is based on estimates and assumptions made some time ago about what may occur in the future. All plans and estimates have a degree of error built in; it is impossible to precisely predict the future of a complex system such as a project. Similarly, the measurement of the actual situation is prone to observational errors; key data may be missing or the situation misinterpreted.
So how do you decide if the measured variance is real and significant enough to warrant corrective action? I suggest considering the following:
1. Does the reported variance line up with your expectations?
2. Is the variance significant?
3. Is a solution viable?
Let’s explore these in depth.
Does the reported variance line up with your expectations?
Try looking at a couple of different monitoring systems, such as cost and time. Do the two systems correlate, or are they giving you very different information on the same group of activities? If they correlate, perhaps your expectations are misplaced. If they are giving you different information, there may be data errors.
Is the variance significant?
If the predicted slippage on the completion date for a key milestone over a series of reports is bouncing around, any single measurement within the noise factor is likely to be insignificant.
Trends, on the other hand, highlight issues. Sensible control systems have range statements that indicate the variance is too small to worry about if it is inside the allowed range. This general rule is modified to take trends seriously and to require action to correct negative variances close to a milestone or completion.
Is a solution viable?
Other situations are simply not worth the cost. There is no point in spending US$10,000 to correct a -US$5,000 variance. However, this decision has to take into account any effect on the client and your organization’s reputation. Cost overruns are generally internal, whereas late delivery and quality issues may have a significant reputational cost, affecting stakeholder perceptions.
Where a viable option exists to correct negative variances, corrective and preventative actions need to be planned, prioritized and implemented. There is no point wasting time on a controls system that does not generate effective controlling actions.
Second, implementing corrective and preventative actions requires the resources working on the project to do something different. Variances don’t correct themselves, and simply telling someone to catch up is unlikely to have any effect. Sensible management action, decisions and leadership are needed to physically change the situation so there is a correction in the way work is performed. This is a core skill of every effective manager.
I’d love to know: How do you deal with variances in your projects? Please share below.
By Ramiro Rodrigues
The term path is used for a sequence of activities that are serially related to each other.
Imagine, for example, that your colleagues have decided to organize a barbecue. After dividing up the work, you are responsible for hiring the catering services. For this task, you are likely to have to look for recommendations, check availability and prices, analyze the options and then choose the best one. These four activities are a path. In other words, they are a sequence of activities that must be carried out sequentially until a final goal is achieved.
A project manager’s job is to estimate the duration of each planned activity. And if we return to our example, we could consider the possible durations:
This sequence of activities will last 40 hours, or five workdays. And since the whole barbecue has been divided among various colleagues, other sequences (or paths) of activities—such as choosing the venue, buying drinks, organizing football, etc.—will also have their respective deadlines.
The critical path will be the series of activities that has the longest duration among all those that the event involves.
Let's imagine that the longest path is precisely this hiring of the catering services. Since the process is estimated to take five days, the barbecue cannot be held at an earlier time. And if it were held in exactly five days, all the activities involved in the path have no margin for delay. This means that if, for example, my analysis of options is not completed on the date or within the duration planned, then the barbecue provider will not be selected in time, which will invariably lead to the postponement of the barbecue—and leave a bad taste in my co-workers' mouths.
Under the critical path method, there is no margin for delay or slack. If there is a delay in any activity on that (critical) path, there will be a delay in the project. At the same time, other "non-critical" paths can withstand limited delays, hence the justification of the term.
It is the duration of this path that is setting "critical" information for all projects—when all the work will have been completed.
Do you use the critical path method in your work? If so, what are your biggest challenges?
Award-Winning Metrics For 2018
by Kevin Korterud
What are the best metrics for determining if a project is about to experience schedule, budget or quality slippages? These metrics are best categorized as delivery volatility metrics.
Executives already know when a project is in trouble — they are more concerned with those projects whose trajectory is on a currently unseen course to trouble.
PMI offers guidance on project metrics to help detect delivery volatility, such as the Cost Performance Indicator and Earned Value Management. While project reporting will likely have one or more of these metrics, I got to thinking what other metrics would indicate the potential of delivery volatility.
An additional complication is the various approaches used today, including agile, waterfall, company custom, software product, service supplier and regulatory. These can all generate their own set of metrics.
While pondering this question watching TV one evening, I noticed a multitude of movie, theater, television and music award shows that tend to occur this time of year. A characteristic of these shows is the numerous categories that are awarded to nominees — Best Supporting Actress, Best New Pop Group, Best Special Effects and so on.
As I was organizing my thoughts around metrics, I figured: Why not use award show categories to help shape an answer on which metrics would best suit early detection of delivery volatility?
As the Master Of Ceremonies for the 2018 Project Metrics Award show, here are a few of the winners:
As our projects become more complex and more numerous, the ability to deliver on a set schedule becomes more important. The SPI has the great benefit of comparing actual and planned progress in an objective manner: earned value/planned value.
The true power of SPI comes into play when selecting a method for earned value accumulation. Assuming work plans are at a level of granularity where task progress can be measured within a two to four week window, a conservative earned value scheme such as 0%/100%, 25%/75% based on task start and completion is a very objective means of calculating progress.
With these conservative schemes, you capture value when the tasks have started (when resources are truly free to work on tasks) and whether the task has been completed (usually with acceptance of completion by a project manager or stakeholder).
Given today’s tight delivery timeframes, as well as the need to coordinate delivery with other projects, SPI is a good indicator as to the schedule fitness of a project.
2. Best Supporting Emerging Metric: Functional Progress Metrics!
As I shared above, there are now a multitude of methods available to run projects. From these methods, all sorts of new metrics are available to project managers to identify delivery volatility. These metrics can include completed user stories, forecast backlog, project burndown, build objects, test case performance and many others.
In addition to these new metrics, a whole host of new waterfall, agile and other tools have come into play that capture functional progress outside of the traditional work plan tasks and milestones. In fact, work plan detail requirements can be relaxed when these tools are used to shed light on the functional progress of a project.
The power of these functional metrics is that they allow the next level of inspection underlying project phases, tasks and milestones to see delivery trajectory. For example, being able to see the detailed completion progress of requirements, build objects and test cases in automated tools allows project managers to catch underlying barriers to progress before it is revealed in a work plan.
As project managers, the universal outcome for our efforts is that we need to create value for our project executives and stakeholders. While activities can lead to creating value, our mission revolves around the production of deliverables in a timely manner to fulfill a project value proposition.
The inherent power in providing and approving deliverables in a timely manner is that they are completely objective means of progress. No matter what method, effort, dependencies, resources, tools or other constructs of project management are employed, deliverables are an indicator of whether you are making progress. The track of deliverables being created, reviewed and approved on schedule means you are making definitive progress toward value.
Creating a track of deliverables and their targeted completion dates with progress that can be monitored through other metrics allows a universally understood path to project completion. For example, if a deliverable has not yet been approved by stakeholders, you are making visible a potential schedule delay that would impair future work activities.
To host your own 2018 project metrics award show, one does not need a spotlight or trophies. You just need to think about what metrics can serve to detect early signs of delivery volatility beyond the self-declared green/yellow/red stoplights that are typically found in project status reports.
If you were handing out your very own 2018 project metrics awards, what categories would you select? What would win?
by Taralyn Frasqueri-Molina
In a small business, like a startup, organizational project management (OPM) may seem too big. At a large blue chip, layers of OPM may be standard operating procedure. But what if your org is somewhere in between? On one hand, you're past the days of moving furniture yourself, on the other hand, you're not yet cutting paychecks for 2000+ employees.
First, let's establish that OPM is a good thing. Linking strategy with implementation across an organization to deliver on portfolio promises and realize value is, trust me on this one, a good thing. But OPM at scale is even better. And that is because if you don't scale OPM to where your org is right now, it may seem that OPM is too complex to even attempt at all.
And if OPM is a good thing, then no OPM is probably not so good.
I've seen what happens to a business that doesn't have an OPM strategy in place. The business is moving along successfully but then the stumbling starts, and then maybe stops, but then it starts up again and continues unabated. Teams are frustrated that progress has halted and find they're taking the blame or blaming each other. Leadership pushes the same answers to newly arisen problems—work harder, faster, longer.
The Benefits of Scaling
OPM at scale ensures the strategy that your entire enterprise is about to adopt is the right fit.
Too light (but it may work for a startup), and your undertaking becomes inconsistent, priorities become ever-changing because there's no clear focus. The entire system is not reliable enough to deliver.
Too rigid (but it may work for a Fortune 500), and you may get in your own way with bottle-necking processes, decision-making by committee, waiting for an approval exit gate that never arrives, wasting time because the system is not flexible enough to deliver.
Where too much process is a hindrance (but may work for a large org) and too little is volatile (but may work for a fledgling company), start with some core principles that are key for your org and build from there.
An OPM at scale strategy could look something like this:
At your next quarterly review, examine how your custom OPM framework is doing. Are you all still aligned on, not just the goal of your portfolio, but the goal of your OPM strategy? Ready to go bigger and start maturing your framework? Or instead do you need to scale back?
What experience do you have with implementing OPM to scale?
Want to see a fully baked standardized model, take a peek at PMI's Organizational Project Management Maturity Model (OPM3®).