Saying 45% go over budget is bad enough. But it’s downright terrifying to add that 17% of projects go so badly wrong they threaten the very existence of the company.
Reichental (@avida) had other scary numbers, but the cause is all down to people, he said. Some of the reasons in an IBM survey are shown in the graphic below.
Citing the example of a small company working off Excel spreadsheets that needs to move to a database, Reichental said project complexity is usually underestimated.
For example, the users may have developed an ad hoc versioning system. They may have an informal security arrangement to protect data.
And, worst of all, business processes are undocumented and locked away in individuals’ minds.
To tackle these situations, Reichental had three tips.
MVP: A minimum viable product (MVP) is the bare minimum. “Make sure you are building for version one — no bells, no whistles,” he said.
Despite requirements gathering, it is probable that the programmer did not fully understand the scope of the problem and/or the customer did not fully understand their own needs.
Streamline: In the same way “a book is not a movie,” a process of strung-together spreadsheets will have to change in many ways when automated.
“Certain parts of the original book are extended out to make it work better and certain parts are left out,” Reichental said.
Boiling Oceans: “Engineering and architecture have a tendency to over-engineer the problem,” he said. Reichental said IT solutions should be right sized.
For example, if there are 50 customers, the new product should be designed for 75 or 100. It might be nice to have 1,000 customers.
But if they don’t exist yet there is no point building for them given how easily systems can scale for them. “Databases are really fast. Hardware is cheap and the cloud is your best friend.”
Pursuing PMP certification? The PMBOK Summarized is available for free here.