No team has more potential to improve
company performance than IT.
Gartner found that 3 out of 4 CEO’s don’t think the IT department understands their business, and 3 out of 4 employees don’t think IT adds anything that helps them do their jobs.
The customer has spoken. Most IT departments don’t have a good grasp on what their business counterparts are trying to do. Business-people blame IT for that failure—and they have a point—but recent neuroscience discoveries have revealed it’s not all IT’s fault. The business plays a part too.
If we’re going to solve the rampant problem of IT project failures, and help IT realize its promise as being the one group within an organization with the greatest potential to improve overall performance, then we’re going to have to dispel some myths, break some bad habits, and replace them with scientifically valid, battle-tested methods that actually work.
We’ve got those methods. Our mission is to share them. It’s time to bridge business and IT. Click here to schedule a free consultation.
3 out of 4 IT project failures happen for one reason.
When ‘what you’re trying to do’ is in question, ‘what you need to build’ to reach that goal is impossible to answer. That’s why failures to communicate what the business needs causes 75% of all IT projects failures. That’s also why we take a different approach—one that goes back to basics to answer those questions.
Business is about execution. Whether you build a product or deliver a service, you move a ‘ball’ from Point A to B as fast as you can to generate profit. That sounds like a linear exercise—it’s not. Execution is a cycle with four phases. Workers do the work. Managers organize and schedule it. Analysts assess performance. And executives refine the process to do better next time.
The only reason to implement technology is to improve your ability to execute, but you have to understand the business process and execution cycle first. Historically, there’s not been a good way to do that. Now there is!
If you’d like to start bridging business and IT click here to schedule a free consultation.
'Silent Requirements' cost US companies $400 Billion a year.
It’s been called a communication problem. It’s actually a function of silence. It’s all the things the business knows that they forget to share, all the questions the tech team never knows to ask, and all the assumptions they both make but never confirm. These ‘silent requirements’ are the problem.
Research by the IEEE and others has shown that roughly half of all IT staff time is spent fixing issues that could, and should, have been done right the first time. They’ve also found that it’s anywhere from 36 to 100 times more expensive to fix a bug after the fact than to catch it up front. Projects that limp into production but require constant rework waste $400 Billion a year. Projects that fail out right only waste $100 Billion. In light of these findings, adopting an attitude of, “we’ll fix it later” can only be described as financial idiocy.
Until now, there hasn’t been an easy way to uncover a project’s silent requirements. Now there is. Click here to download our white paper and toolkit to bridge business and IT. Or, click here to schedule a free consultation.
If understanding what the business is trying to do
is the foundation of an IT project, and most foundations fail,
Our perspectives on project requirements are shaped by our experience. People gravitate to what they know. There’s nothing malicious about that. As neuroscience has recently shown, it’s how we’re wired.
Technical people ask about the number of records, transaction volumes, etc. That’s perfectly valid at a micro-level. Businesspeople ask about what the business is trying to do and why it’s important. That’s perfectly valid at a strategic, macro-level.
Those two perspectives are equally important. The former provides detail. The latter provides context. One can’t work without the other. Unfortunately, we’re getting the details but not the context because the technical people building these systems don’t know to ask the business questions they need to establish that context. That’s why so many of our IT projects are failing.
Having studied this issue as a group for 300+ years, we’ve not only spotted the pattern, we’ve found a solution. Our mission is to share it.
The process required to run software projects is different
from the one required to understand business.
The Project Management Institute (“PMI”) publishes the globally recognized gold standard for project management, the Project Management Body of Knowledge or “PMBOK”. The PMBOK embodies the best practices of the profession in 49 processes. Process 5.2, Collect Requirements, is unarguably the most important as it impacts virtually every other process. An accurate assessment of business requirements is the foundation on which the entire project is based. If the foundation is bad, everything else will be too..
As useful as the PMBOK is, it has one limitation—it’s generic. It’s designed to be used in any industry. When it comes to collecting requirements, the PMBOK suggests many ways to asks questions, but it never tells you what questions to ask. It just assumes you know. Given the failure rates of of enterprise IT projects, it’s pretty obvious that most practitioners don’t know the business questions they need to ask.
We think we can help. Having managed enterprise IT projects as a group for 300+ years, we know the holes in governance models, and we know how to plug them. Our mission is to share that knowledge.
Neuroscientists have also discovered
that humans don’t control their thoughts and actions.
In the last 20 years neuroscience has discovered some things that help explain our challenges bridging business and IT. Foremost among these is that humans build mental models for everything. We literally can’t think without a model. We remember these models as stories. Unfortunately, these stories aren’t precise. They’re high-level summaries that are riddled with errors.
When a project team member interviews a SME to learn what a business process requires, a miscommunication usually follows that would be comical if it weren’t so detrimental to the project. The SME conveys the inaccurate and truncated story they’ve internalized about that process—unconsciously overlooking critical details the tech team desperately needs. The interviewer errantly assumes the SME, being the process expert, has accurately communicated everything required.
Armed with what IT believes to be the complete requirement, they code to that specification—only to be stunned later by the SME’s criticism of a system that doesn’t do what needs to be done. Arguments and accusations ensue. Each side derides the other as incompetents. The delays and cost overruns pile up. If any of this sounds familiar, we have your solution.
The details of the process the SME unconsciously omitted were not permanently lost—just temporarily misplaced. The SME still has the details buried in their head. They just need help excavating that information. We have an easy way to do that.
Apollo had millions of parts that had to work perfectly.
NASA knew the moon shot was too big for any person or team to get their heads around. So they figured out exactly what they had to do to get to the moon and back safely. They broke each objective down into interim steps that had to be successfully completed before proceeding. They turned the entire project into a checklist to be sure they executed each step correctly. Then at every step along the way they checked those lists to make sure they’d done everything right.
They didn’t trust their memory. They didn’t trust their communications. They didn’t trust their assumptions. Some of the smartest people on the planet didn’t trust themselves—because they knew they couldn’t and the costs of failure was too high.
Really smart people acknowledge their limitations and create guardrails to accommodate behaviors that no one can control. Fools pretend they don’t have any limitations and charge headlong over cliffs.
Sadly, it appears that many have forgotten this lesson. We’d like to refresh their memory. Click here to schedule a free consultation.