Do projects go from green to red overnight? If they do, what is the likely cause?

“Projects do not go from “green” to “red” overnight.” (Kerzner, 2017, p. 46) Projects are typically on a trajectory that takes them from “green to “red”, the road to red is littered with early warning signs depicting this negative trajectory which are either not well understood or ignored. It is the role of the project manager to identify and understand the signs of a failing project and alter its trajectory before it fails.

Should a firm-fixed-price contract have been awarded from the ERP effort?

Based on the case study I think the answer to this question would be, no. I would also agree that a firm-fixed-price contract for an ERP (Enterprise Resource Planning) implementation effort is very risky given the size and scope of a typical ERP implementation. “The key to a successful fixed-price implementation is having the deliverables clearly spelled out in the agreement.” (Should You Choose A Fixed-Fee Cloud ERP Implementation, 2014) Because of the size, scope, the number of stakeholders involved, etc. in an ERP implementation the probability of cost and time overruns is high.

With this said I think that an ERP project in the modern SaaS era can be successfully scoped and delivered in a firm-fixed-price model. More and more customers are willing to go from zero to something using cloud-based ERP systems such as SAP HANA, Infor, NetSuite, etc. In these scenarios, it is possible to write and control a tight scope and deliver value to the customer.

Successful execution of a firm-fixed-price (FFP) contract relies on establishing firm requirements for new systems and developing and implementing solutions using mature technology, design, and implementation techniques. (Callaway, Hastings & Moeller, 2018) This was not the case for the engagement between Mannix Corporation and Prylon. If the ERP system was being the deployed as a SaaS solution, or a well-defined greenfield build rather than the multi-vendor, multi-application integration project that Mannix was attempting to execute on, a firm-fixed-price contract may have been appropriate.

What is the ultimate goal of a recovery project?

The ultimate goal of a recovery project is to assess, reset and restart the project with the objective of closing our the project and delivering the maximum value to the customer. To do so, the project manager (Jerry) must understand in detail what has occurred in the project to date, redefine the project scope, reset and manage stakeholder expectations, lift the project teams morale, restart and execute. The successfully execute the recovery project the project team must operate transparently, communicate, heed the warnings of past mistakes, metric progress, function as a team and stay positive.

Do stakeholders expect trade-offs during recovery?

It is the job of the project manager and the project team to ensure that the stakeholders expect tradeoffs during recovery. In the case study, Jerry does a good job of identifying trade-offs, developing a game plan and presenting these trade-offs to senior management at Prylon. Jerry presents what I will call the quadruple constraint of time, cost, value, and scope. Honestly, this is the First time I have seen these four constraints referenced like this. Typically I see either the triple constraint model (cost = f (scope,time)) or the value triple constraint model (value = f(scope,capability)) used. (Baratta, 2007) I am a huge fan of the value triple constraint because I agree that the measurement of the expected and actual business success of a project is more important than just the ability to meet a cost and budget target. Focusing on cost as a function of scope and time is a horrible starting point for setting expectations and delivering project value. We know these projects are dynamic, as is the case for so many technology implementation projects today, I believe this is why we have seen a shift from waterfall to hybrid to agile project frameworks. (Hartman, Griffiths, Rothman, Fewell, Kauffman, Matola, & Agile Alliance, 2018)

References

Baratta, A. (2007). The value triple constraint: measuring the effectiveness of the project management paradigm. Paper presented at PMI® Global Congress 2007—North America, Atlanta, GA. Newtown Square, PA: Project Management Institute.

Callaway, M., Hastings, S., & Moeller, A. (2018, March). Applicability of fixed-price contracts for successful cost control. In 2018 IEEE Aerospace Conference (pp. 1-16). IEEE.

Hartman, B., Griffiths, M., Rothman, J., Fewell, J., Kauffman, B., Matola, S., & Agile Alliance. (2018, September 18). What is Hybrid Agile, Anyway? Retrieved October 31, 2018, from https://www.agilealliance.org/what-is-hybrid-agile-anyway/

Kerzner, H. (2017). Project Management Case Studies (5th ed.). Hoboken, NJ: John Wiley & Sons, Incorporated.

Should You Choose A Fixed-Fee Cloud ERP Implementation? (2014, March 27). Retrieved October 31, 2018, from https://www.bspny.com/blog/should-you-choose-a-fixed-fee-cloud-erp-implementation

Scott, good news.  I don’t think we disagree, I think it’s more philosophical than a simple disagreement. 🙂 I believe projects go from green to red in an instant from a perception perspective, but in reality, it’s not really how it happens. The number one place I see projects go from green to red is when the SoW (Statements of Work) is signed and passed from the sales team to the delivery team. We create scopes that more often than not define workstreams and deliverables, as the author of these SoWs we make assumptions, interpretation is often subjective and often steered by someone who wants to get the deal signed, this is where the project started going awry. The warning signs could not have presented themselves any earlier in the project. In the time it took the customer to sign SoW lathered in misset expectations the project went from green to red, and it hadn’t even started. I believe all the unforeseen issues, that happen “out of the blue” were foreseeable in the scoping process.

In your Toyota example, the project was red before it even started. I don’t believe in mistakes, only decisions that have poor outcomes. The stars were aligned in this example to make a quick decision, not do exhaustive due diligence, possibly to obscure some facts, everyone wanted the fast track, and they wanted the project to succeed, but hope is not a strategy.

Who knows, maybe it was an election year, maybe Toyota coming to town, the economic growth, public sector job growth prompted that late-night cell phone call where both Toyota and the politicians decided that they should obscure this little tidbit and push forward, knowing they would have to address the spring pygmy sunfish in the future. Yes, it seemingly went from green to red overnight, but did it? 🙂

Andrew, the poorly designed and constructed infrastructure dependency, I know it far to well, so often obscured during the discovery phase.

I liken the know of obscured/excluded infrastructure details to painting the street signs with different names at “Wimp Junction”. 🙂

The emergence and adoption of DevOps, cloud, etc. can be traced to the infrastructure dependancy you describe. Composable infrastructure, commodity hardware, cloud allow for infrastructure agility and elasticity which enable quickly adjusting to changing needs.

Release cycles give way to, canaries and blue-green deployments, and the focus is on iterating and automating recovery rather than rigid release cycles and testing which provides a false sense of security that a release is tested, production ready, etc.

I don’t do recovery projects.  I’ve run a sizable service delivery business for the last 18 years, and I have a simple rule, don’t rush me.  I am here to protect you from yourself, yes there are knobs we can turn and levers we can pull, but my scope will be comprehensive, and if I have dependencies like infrastructure requirements they will be called out in my scope. Measure five times cut once, and oh yeah, I am happy to walk away.

Want a fixed pice scope, probably going to be a rigid waterfall project, that I’ve executed a thousand times, in a greenfield environment where I own all the dependencies, have total trust and partnership from the stakeholders, etc… I will deliver on time and budget. If the scope is more nebulous, I will still estimate the project based on experience, defining epics and stories, assigning story points and calculating an estimated cost. We keep the sprints to a max of two weeks, holding daily standups and tracking burndown closely.

Andrew, excellent post, as usual. I agree that a project can go from red if there is an SME that somehow evaporates from the project and now the project t is FUBAR because a major dependency can’t be satisfied. But as you point out the projected started yellow, because you had a major dependency in the project which relied on a single SME, no one asked the question “What happens if Johnny gets hit by a bus?” I hear it all the time among salespeople, I talked to so and so and he knows this tech why can’t we well a project? I don’t like were in this business because we have a guy/gal who knows the tech, that’s not a business, it’s not if your gonna get burned, it’s when.