Tag: Project Management

What Exactly is Agile Project Management?

Written by James Hannon on January 24, 2017. Posted in Articles. 3 Comments on What Exactly is Agile Project Management?

In the explosion of Agile deployed in many companies has brought project management to a crossroads.

Project managers are grappling with the fact that years of experience and training have left them with a need to adapt to more Agile philosophies or be branded as dinosaurs. The advent of the new Agile Certified Practitioner (ACP) from PMI has shown PMI recognizes the need to build in more Agile aspects into the Project Management Book of Knowledge (PMBOK). In many companies, management looks at project management as either a necessary cost center or as an area where resource dollars can be saved.

Can Agile and Project Management Co-Exist?

The short answer to the above question is YES. The project manager of today must realize one thing – adaptability is the way to survive and thrive in every company. The pace of technology and change is not rapid but frenetic. The project manager that adapts to Agile philosophies realizes quickly they must take the best of PMBOK and Agile and come forth with a workable solution for their company. The new Agile project manager realizes that stability and time with no change are a thing of the past. The Agile project manager can take the project manager skills they have learned and transform themselves into a scrum master or a vital cog in making sure they become Agile program/portfolio managers. The Agile program or portfolio manager plays a key role in making sure multiple scrum teams communicate on the combined deliverables they are producing. The communication of Agile teams is a troublesome aspect of Agile and unless a company fully leverages Scaled Agile they struggle to ensure a coordinated vision. The roles previously described give new and exciting options for the project manager to explore and bring a new and refreshed Agile project management discipline to their company.

The Real Role of the Agile Project Manager, was it Always There?

The Agile project manager, at their heart, is a change agent. The Agile project manager has to be a change agent and mentor, teach and preach the idea that change is a law of nature and the organization must not shy away from it, but embrace it fully. The one aspect of good Agile is the mantra of continuous improvement. The structure and agility of companies today is dismal, and the courage to implement disciplined continuous improvement takes a great deal of courage.

The application of good adaptable, realistic project management practices can be thought of as a base for the Agile project manager.

The deployment of good Agile usually requires organizational changes, sometimes major, to ensure the Agile transformation process works. These underlying structural changes in companies need a champion and this is where the Agile project manager must take the lead. The Agile project manager is uniquely positioned to advocate, manage and lead changes they understand organizations and what needs to be done to make them more efficient.

So What Now?

The project manager should first realize the need for change and adapt and embrace the role they have as the lead change agent. The methodologies of today are just that – methodologies. The truly successful project managers keep one eye on the current environment and one eye on the future. The new Agile project manager will take whatever tool or methodology is available and should not be a purist. The adherence to purity will doom the Agile project manager. This ability to adapt in Agile and the new rules spelled out in this article will hopefully make project managers realize they oversee their destiny, not a bureaucratic and bloated management.

The Why What and When of a Decision Log

Written by Brenda Hallman on January 23, 2017. Posted in Articles. 3 Comments on The Why What and When of a Decision Log

Can you relate to that project that feels like it has been dragging on a little too long?

Moreover, your team is sitting in a conference room drowsy from preparing the final touches when one perky creative soul, who by the way missed the first four months of meetings (thus why they are perky), pops up with a question ‘Why are we doing it this way? We should look at a different option?’

Once the collective groans subside, everyone starts in on a chatter contemplating a different option. “Wait,” you think, “it has already been hashed out!” Quick, where are your notes? Where is that email talking about a different option? Was it in the meeting minutes somewhere? “When was that again? February?” This is all too familiar. You can’t quickly find the results, and you desperately want to stop all of the cross-conversation and new found excitement that has roused up the room. Then you sit back and remember, “Ah yes, I have a decision log!” You swiftly scan it, find the related item and pound your gavel on the table to gain everyone’s attention. It will all be fine, we are on the right track, and we don’t need to spend another moment of discussion because it was already agreed which would be the best action. Phew!

Utilizing a Decision Log, which is a list of critical decisions agreed upon throughout the project, has not yet leaped into mainstream project management practice, although it has started to gain traction being viewed as beneficial for recording impactful decisions and serving as a central repository for those decisions.

Why Do It?

The concept is a simple one. Once a discussion begins regarding a project, decisions are being made with some decisions essential for the direction of the project. Documenting those in a central location can be of value throughout the project as a quick reference and communication tool to assure everyone is aware of the direction.

Decisions may not always be agreed upon by the team members. Rather than opening a discussion for debate each time the topic arises, it is better to resort to the documented decision and move on from the topic.

Additionally, these decisions may be made in a forum that does not involve all team members, and they may be hidden in meeting minutes or informal email messages. Providing a standard method to document and communicate decisions can assure everyone is aware, avoid lack of clarification, and can be used as a method to focus team members when debate arises.

Decisions can be revisited when necessary, and may even be changed when new information presents to the project. Team members who raise valid points that counter a decision should be heard and their opinion valued as it may offer a better course of action.

What Information to Include?

A decision log is a beneficial communication tool to assure all stakeholders are apprised of how a decision was reached, what other options were considered, and who is accountable for the decision. It provides guidance to the team members and can eliminate potential confusion. The format you use may be a spreadsheet, automated log, or another method that suits your environment.

The primary information to capture includes What is the decision, When was it made, Why it was made, and Who made it. Other information may be captured as well and may vary based on the project needs.

When to Include a Decision?

When to include an item in the log involves striking a balance between what is valuable to have recorded versus what is too detailed, and will take thought. As well as considering the overall audience, team members and project dynamics also consider these things:

Topics that are frequently debated or where there is often disagreement.
Decisions that may be confusing or not clear to all stakeholders.
Those made that impact the direction or future work of the project.
When alternatives exist, but only one must be selected.
Decisions made by leaders, or others outside of the project team, which will impact the work of those team members.
Those that impact what or how a deliverable will be achieved where it may be different than some stakeholders expect.
Items that may not seem significant but can cause issues if not understood.

As a project manager, you must judge what your stakeholders will view as too much detail. You also must consider not eliminating items that you think are valuable to minimize detail.

There you have it!

No one wants more documentation. That goes for the individual who must create and maintain it as well as the recipients who do not want yet another attachment to read. The value of the log is for the project manager to have a centralized location to capture items that may cause debate or slow progress or for those who are included to search for information on the project materials instead of hunting down the project manager. This can turn into a time-saver and worth a try it on your next endeavor!

From the Sponsor’s Desk – The Six Secrets of Project Prosperity

Written by Drew Davison on January 17, 2017. Posted in Articles. 5 Comments on From the Sponsor’s Desk – The Six Secrets of Project Prosperity

Imagine this. Your boss asks you to work with eight countries in West Africa.

The assignment: to support the establishment of practices for the effective and equitable operation of microfinance lending to small and medium size business clients in the region. He tells you it’s vital to the growth of the local economies and to the region as a whole.

That request is probably well outside the comfort zone of most project managers. It’s hard to image where you’d even start. But CESO knows. In fact, they do this kind of thing all the time, with limited financing, a small full time staff of fifty, and a core of seasoned Canadian volunteers. They deliver successfully, time after time, using what I call the six secrets of project prosperity.

Thanks to Leah Oliveira, Director, Communications and Engagement at CESO for the details on this story.

The Situation

The mission of the Canadian Executive Service Organization (CESO) is “to strengthen economic and social well-being in Canada and abroad through engagement of skilled and experienced Canadian volunteers working co-operatively with partners and clients to create solutions that foster long-term economic growth and self-reliance”.

As I recounted in my previous post on CESO, Stronger Economies, Better Lives, CESO focuses on helping small and medium size businesses (SMB’s) as a catalyst for growing individual and community prosperity. Providing funding to those SMB’s is an essential component of that strategy. Unfortunately, traditional lending organizations aren’t always interested or able to serve those needs. That’s where microfinancing comes in.

Working with its network of government and non-governmental organizations, private sector enterprises, clients and its own staff and volunteers on the ground in West Africa, CESO identified available and effective microfinancing services as a foundational need for continued SMB growth and development. While microfinancing was often available, the offerings weren’t regulated to ensure SMB clients were protected from abuse. That posed a potential risk to borrowers and thus a constraint on SMB viability.

The Goal

The challenge, therefore, was to bring together the national microfinance institutions of eight West African countries to define, institute and administer policies and practices that would ensure safe and accessible microfinancing services throughout the region. Consistent oversight of microfinancing practices would enable lenders to achieve a reasonable return on their investments while providing SMB’s with access to the capital needed to start and grow their businesses without fear of abuse. It would also provide a unified, singular voice to work with regional institutions, governments, international partners, the regional central bank, and more broadly with the West African Monetary Union.

The Project

This program started almost twelve years ago and involved some fifty CESO Volunteer Advisors and other CESO staff over that time. Each assignment involved contact with current and prospective SMB clients or microfinance organizations along with other interested parties. The engagements would identify local needs and problems, potential future issues and concerns, current and future risks and opportunities, and potential remedies.
Over time, the outputs from these assignments were rationalized, assimilated into a broader body of knowledge that became a framework for collaboration across the stakeholders involved, locally, nationally and finally across all eight West African nations.

The Results

Those years of work culminated in the first annual general meeting of the West African Microfinancing Foundation in October of 2016.

Microfinance in West Africa is now a dynamic economic and social sector which empowers more than 9% of the total population in 8 countries (Benin, Burkina Faso, Ivory Coast, Guinea-Bissau, Mali, Niger, Senegal and Togo) of the West African Monetary and Economic Union. In comparison, traditional banking amounts to 5.5%. According to the available statistics, at the end of March 2015, there were 724 microfinance institutions in the affected region, attracting more than 13.8 million beneficiaries.

Continuing assessment of ongoing performance will focus on the following metrics:

Social return on investment,
Outreach or improved local credit markets – how many clients are being served
Collection performance – how well is microfinance collecting its loans
Financial sustainability – is the organization profitable enough to maintain and expand its services
Efficiency – how well does the organization control its administrative costs.

How Great Leaders Delivered

The six secrets that CESO used to achieve these great results are, in fact, the cornerstone of everything they do. They include:

Mission, Vision, Culture – All of CESO’s operations are framed by their mandate established fifty years ago and mentioned at the start of this article. They are driven by local needs. Their main emphasis is always on strengthening and enabling local clients and partners through knowledge transfer and collaboration.
Human capital – CESO’s focus is on building individual skills and capabilities in the private sector and supporting institutions. To that end, they select and assign highly skilled Canadian Volunteer Advisors to train and mentor local entrepreneurs and institutional staff to realize sustainable change. CESO has mentored and trained almost 6,000 people in their target communities over the last two years alone.
The long view – We know that projects that are spawned by a strategic plan and guided by an organization’s strategic direction tend to be more successful on all fronts. So, it’s no surprise that CESO’s remarkable record of success can lay claim to a similar enabler. At least 85 per cent of CESO projects are conducted under the auspices of a Partnership Action Plan, including the microfinance initiative. The plan is developed by a CESO Lead Volunteer Advisor in collaboration with local partners. It provides the blueprint for assignments that will be carried out over the entire course of the multi-year timeframe. The remaining 15 per cent of projects are purposefully constructed under a “fee for service.” These projects tend to come from new, often smaller partnerships that serve in many ways as pilot projects for both CESO and the partner, many of which are developed into multi-year partnerships following the test project.
Networks of Relationships – CESO’s Country Representatives look after business development on a country by country basis. They find and identify partners and clients, build and sustain those relationships, manage local government relations and liaise between CESO, the local, regional and national governments and Canadian embassies. The networks are formed and nurtured independent of any particular project. Yet, they are what allow CESO to frame the opportunities, engage the required stakeholders and launch initiatives quickly and effectively. The relationships, for the most part, are already in place.
Partnerships – CESO’s partnership model is adaptable to different situations as well as being scalable to various sizes of enterprises and undertakings. The microfinance initiative involved the formation of partnerships across four levels in West Africa, with individual entrepreneurs, building capacity in local microfinance institutions, advising national micro-finance regulatory institutions and at a regional level with the West African Monetary Union. The overall partnership model facilitated and reinforced the formation and operation of those separate groups. That’s just the way CESO does business.
Best practices – Every assignment and every project goes through a formal evaluation process with the participation of involved partners, clients and CESO staff. Lessons learned are formalized and add to the best practice body of knowledge to help improve future performance. CESO even has a formal position called a Knowledge Officer. People in this role are accountable for eliciting and sharing information and best practices and facilitate getting evaluative information back to CESO. If only every organization had a Knowledge Officer or two.

These six secrets to CESO’s continuing success are not generally what come to mind when one thinks about key project success factors. Nor are they always easy to implement in every project situation. In fact, most of these six secrets are typically beyond the scope of any one project. However, CESO’s track record demonstrates the power of the practices to produce consistently sustainable change.

So, be a Great Leader and put these points on your checklist of things to consider so you too can achieve great results. You might not be able to go all in on each practice. But perhaps going just a little way towards CESO’s secret six can give you that critical edge. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework best practices right up front so you don’t overlook these key success factors. You’ll find that CESO’s six secrets to project prosperity are included.

If you are intrigued by CESO’s mission and would like to learn more about becoming a volunteer advisor, at home or abroad, check out their website. It covers the skills they’re looking for and the steps involved to become a volunteer.

Finally, thanks to everyone who has willingly shared their experiences for presentation in this blog. Everyone benefits. First time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights. Thanks

5 Trends in Business Analysis, Project Management, and Agile for 2017

Written by Elizabeth Larson on January 11, 2017. Posted in Articles. 8 Comments on 5 Trends in Business Analysis, Project Management, and Agile for 2017

Since 2009 we have enjoyed reflecting on what’s happened the previous year on projects and making predictions for the upcoming year. To summarize the `trends” we saw in 2016:

Emergence of the Business Relationship Manager (BRM) to maximize value
Agile successes, challenges, and use beyond software
Trends in business analysis and project management certifications
Implications of a changing workforce

Here are five industry trends we see happening for 2017. We’ve added two brief bonus trends at the end of the article.

1. Business analysis as a focal point for scaling Agile

Many organizations are delighted with the results produced on Agile projects, but are struggling with its application on large, complex projects, as well as its adoption enterprise-wide. Many of the discussions focus on which Agile framework works best for scaling Agile. Some of the common frameworks often discussed are scrum of scrums, Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), and Nexus.

Large, complex projects. While there is a great deal of contention about which framework is “best,” there seems to be an agreement that there is a need for coordination, integration, and communication among Agile teams related to the solution being developed. Regardless of the title of the person doing this work, it is business analysis work. And it’s work that has always been needed on large, integrated projects—the coordination of dependencies, security, business and technical impacts, and version control.
Enterprise-wide Agile. Many large organizations have adopted Agile in a hodgepodge of ways, and these different areas have become quite fond of doing Agile “their” way. Adopting Agile across the enterprise will require skills of people not only familiar with Agile, but also with understanding the Agile current state and working with stakeholders to reach consensus on a unified future Agile state. This will involve being able to influence, resolve conflict, and to think both creatively and critically—skills well suited to experienced BAs.

2. Digital Transformation: Profound Change for Business Analysis…or is it?

The “digital transformation” movement means we must change the way we handle business analysis and requirements. Or does it? Consider two trends commonly mentioned today.

Cloud Computing. Security is a bigger concern when storing data in the cloud than if it is on-site under “lock and key.” Considerations for recovering data must be employed over and above normal backup and restore. Access rights are also more complicated than with traditional applications.
Mobile apps. Mobile applications provide data for sensitive banking, investment, or insurance applications. Security is a bigger concern on mobile devices given they are, well, mobile. It is much easier for a thief to access a bank account from a mobile device than a desktop. Modern apps need to have “mobile responsive” features and usability.

What we conclude is that these two technical trends will continue to affect business analysis. The trend, though, is not so much with functional requirements as it is with non-functional requirements (NFRs). The two examples above feature important NFRs including security, accessibility, recoverability, and usability, including user experience. NFRs are traditional aspects of business analysis, and any profound effect on it is that we will need to pay even greater attention to them with digital transformation.

3. Freelance BAs and PMs in the Gig Economy

Currently 40% of the US workforce is part of the Gig or on-demand economy¹ and that number is growing. Intuit breaks this on-demand economy into 5 groups.² We describe these groups below and briefly discuss how they apply to the project manager (PM) and business analyst (BA). Here are the 5 groups:

Side Giggers (26%). These are PMs and BAs who want to supplement their existing income. Examples include PMs and BAs who take vacation, days without pay, or who work off-hours to do training classes or short-term consulting gigs.
Business builders (22%). BAs and PMs who are tired of working for others and want to be their own bosses fall into this category. Many of these will create their own companies and hire others. We can expect these companies to be based on the owners’ experience in project management and business analysis. Examples include consulting and training companies.
Career freelancers (20%). These PMs and BAs love their work, love working independently, and want to use their skills to build their careers, not to build a company that hires others. These folks usually establish themselves as independent contractors with their small own company, usually an LLC.
Substituters (18%). PMs and BAs who want to work in the gig economy temporarily. Whether laid off from their former organizations or for other reasons they view “gig” work as temporary while they look for full-time employment.
Passionistas (14%). PMs and BAs who love what they do and are primarily motivated by their desire for greater flexibility than is usually provided by a more traditional organization.

4. The shifting sands of the BA and PM roles

Many project professionals find their roles changing so rapidly that it feels like the earth is shifting below their feet. Roles are being combined (BA and PM or BA and QA) or being torn apart (formerly hybrid PM/BAs are now full-time PMs or BAs). In some organizations BAs thrive on Agile projects working hand-in-hand with product owners (POs), while in others become part of the development team doing testing because there are no BAs,. PMs become scrum masters as do BAs. Sometimes the BA becomes a product owner, but one without the authority to make decisions.

In addition, both BAs and PMs are working strategically, doing business cases and recommending enterprise-wide solutions. And more and more organizations recognize the importance of the business relationship manager (BRM), to maximize value and help set the strategic agenda.

So what is the trend? For the foreseeable future, roles and titles will vary widely from organization to organization. Equally certain is that both project management and business analysis work, both strategic and tactical, have always been required and will always be needed, regardless of the role or the title or the role.

5. Generalists helping teams to self-organize

If descriptions of job openings are an indication, specialization seems to have wide appeal. But breadth of capabilities will continue to provide the flexibility that organizations need to respond to the hyper pace of change. BAs who code. Engineers who do project management. It’s the number of arrows in the team members’ quivers that defines an organization’s competitiveness – and contributes to the team’s ability to self-organize. Not only do organizations need self-organizing teams, but the teams themselves also need the flexibility to pick up tasks that are ready to go, so the more diverse the team members’ skills, the more work can be done in parallel and completed sooner.

Although varied work appeals to many younger workers, this isn’t just about attracting millennial talent. Self-organizing teams provide the structure organizations need in order to react quickly. Self-organizing teams and the ability of team members to wear multiple hats and get things done as they see fit will continue to become the best way for organizations to respond to external influences. The self-organizing team is not a new thing, but it is going to increasingly become the norm.

Two bonus trends

Short business cases and quick value. The trend is to provide business cases on slices of the initiative, slices that can bring quick value to the organization, rather than spending weeks or months detailing out costs and benefits and a return on investment showing a multi-year payback.
Dev Ops³ This trend relates to the first and fourth trends, scaling Agile and the shifting project roles. BAs and PMs now find themselves participating as DevOps Engineers on Agile teams that emphasize collaboration not just between the customer and development team, but also among such areas as development, operations, security, infrastructure, integration, etc.

Footnotes:
1 Forbes, January, 2016
2 Intuit Investor Relations, February 3, 2016, http://investors.intuit.com/press-releases/press-release-details/2016/The-Five-Faces-of-the-On-Demand-Economy/default.aspx
3 Dev Ops is “a cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly-changing resilient systems at scale.” https://theagileadmin.com/what-is-devops/. Ernest Mueller, Aug 2, 2010 – Last Revised Dec 7, 2016. He attributes this definition to Jez Humble.

About the Authors

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored five books on business analysis and certification preparation. She has also co-authored chapters published in four separate books. Elizabeth was a lead author on several standards including the PMBOK® Guide, BABOK® Guide, and PMI’s Business Analysis for Practitioners – A Practice Guide.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich loves to combine industry best practices with a practical approach and has contributed to those practices through numerous speaking sessions around the world. He has also worked on the BA Body of Knowledge versions 1.6-3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis and certification preparation.

Andrea Brockmeier, PMP, CSM, PMI-ACP, is the Director of Project Management at Watermark Learning. She has 20+ years of experience in project management and related practice and training. She writes and teaches courses in project management, business analysis, and influencing skills. She has long been involved with the PMI® chapter in Minnesota where she is a member of the certification team. She has a master’s degree in cultural anthropology and is particularly interested in the cultural aspects of team development, as well as the impact of social media and new technologies on organizations and projects.

Can you predict if a project is going to be successful?

Written by Phil Jacklin on January 10, 2017. Posted in Articles. 6 Comments on Can you predict if a project is going to be successful?

We all have failed projects. But what if we could predict how likely a project was to be successful. Can we?

There are certainly some factors that we would all agree are definite indicators of a project’s probability of being successful. Take two projects, identical in every way, except one has all resources utilised at 200% of capacity and the other has all resources utilised at 50% of capacity. Everything else is identical. There is universal agreement that the project with over-utilisation of resources is less likely to be successful than the project with under-utilisation of resources. In this very abstract scenario, project success has an element of predictability.

But that doesn’t mean a project with more resource availability has a higher probability of being successful, than a project with lower resource availability, even if all other things are equal. For example, is a project with resources utilised at 51% of capacity, more likely to be successful, than a project with resources utilised at 52% of capacity? The difference is probably negligible. Both projects are equally likely to be successful. But what about a project with resources utilised at 100% of capacity, compared to a project with resources utilised at 101% of capacity? The difference is the same as in the previous example (1%), but is the effect on probability of success different?

So now we have the situation where there is a tipping point beyond which a project’s likelihood of success starts to change, as well as another tipping point later, after which changes have no discernible effect (projects with a 500% or 501% of resource utilisation, for example, are equally likely to be successful). This would give us a success curve, as shown in figure 1.

This leads to the next logical question. What are the values of the tipping points? Of course, that question we can never truly find the answer to. You can’t set up identical projects with different values of resource availability, keep everything else equal, and then run the projects to completion to see which ones were successful and which ones failed. Maybe that means project success is not predictable? Or is there another way?¹

Like we have developed the argument around resource utilisation and shown how that could affect project success rates, there are other variables that we can develop a similar argument for. Keep everything else equal and only alter the amount of budget contingency; Keep everything else equal and only alter the amount of slack on the critical path; Keep everything else equal and only alter the amount of scope creep. All these scenarios will develop along similar arguments to the resource availability example. Whilst we can’t provide absolute measurements and can’t define our tipping points, we can at least develop a theoretical model, a probability of success curve, for how probability of success will alter depending on different values.

Before we come on to how we can use this, we need to think about the effect of combinatorial factors. So far, in all our examples, we have only changed one factor and kept everything else equal to derive our success curves. In our real projects, there are thousands of moving parts and thousands of factors that we might want to take account of. These factors change values at the same time. What effect does that have? Does it have any effect?

If we have a project with 95% resource utilisation and -30% budget contingency, is that more, or less, likely to be successful than a project with 95% resource utilisation and a 30% scope creep? Are scope creep and resource utilisation the deadly duo and when seen in combination, there is an accelerator effect and projects are even less likely to be successful? And how can we measure and validate this?

There is no doubt that combinatorial factors make the whole analysis of project success a good deal more complicated. Measurement and validation of any model, very difficult to start with, now becomes almost impossible and our hopes of finding a model to predict project success are fading. But there are some assumptions and techniques we can use to give us a glimmer of hope.

If we were to build such a model that predicted project success, what would we use it for? It turns out, that an answer to this question, could help us build a useful model for at least one scenario. A model that ranks project success, across a range of projects, relative to each other, would be useful to help us understand which of our projects, across our whole portfolio, are least likely to be successful. Those are the projects that we might review, change, or keep a careful eye on as they progressed. In this scenario, an absolute ‘score’, a ‘percentage probability of success’, doesn’t matter. What matters, is a comparative score. We are only interested in those projects that are low, compared to others.

Our work is simplified considerably with a comparative model. The position of our tipping points does not need to be as exact as the comparative differences still apply wherever the values of the tipping points are set.² The probability of success ‘score’ for different points along our success curve no longer matter either.

As we are only building a comparative model, it’s the difference between the scores for different projects that matter, not the absolute scores. So now, if a project has a 100% resource utilisation, it doesn’t matter what ‘success score’ is given to this point, what matters is the comparison of this score to other scores.

There is still complexity in combining factors, which absolutely needs to be done in any model of worth. No one would argue that project success is entirely dependent on one single factor. Since the ‘multiplier’ effect of different combinations cannot be safely evaluated (you can’t prove that factor A, in combination with factor B, is more likely to lead to a failed project), the simplest thing to do is to combine factors in the least aggressive way (i.e. additive not multiplicative) and to combine all factors in a consistent way. The model will not be perfect, but it will still be valid as a comparative tool to compare project A’s chance of success against project B’s chance of success.

So, what do we end up with? We have a very simplified model that gives us the ability to compare a group of projects against each other, to show which ones are more likely to be successful and which ones are less likely to be successful. It’s not perfect and there’s still work to be done to work out which factors we should be including (1000s is not practical. But do we need 100s to have a good working model, or are 10s of factors enough?). But with enough data to analyse, this problem can be solved. There are also assumptions and simplifications that we’ve had to use to get to any model. Despite the limitations, the model is something we can use in our evaluation of projects – another tool to help us deliver successful projects.

Any model of project success becomes even more useful when we apply human interference and irrationality in to the model, which is the environment that a real project must be delivered in to, but that’s a blog post for another day.
What would you do if you knew your project had a 35% probability of being successful?

Footnotes
1 There is a separate argument that it might not matter. The rate of change, in probability of success, at either side of the tipping point, is so small, that if you were to build a model and set the tipping point at the ‘wrong’ place, the effect would be negligible anyway. This argument degrades once you set the tipping point a lot further away from the place it ‘should’ be, but it does give you an ‘accuracy range’ at which you can place the tipping point and the model can still be valid.
2 This is not quite true, there are a range of places within which our tipping point can be validly placed and not degrade the results of the model too badly. But that range is significant enough for us to have a better degree of confidence in the model.