The Predictable Mindset Test by Geneca
20 Questions Every Software Development Professional Should Ask
Do you have a predictable mindset? That is, can you consistently deliver without surprises?
Some teams deliver on time or on budget, but this alone is not predictability. Being able to deliver exactly what the business needs with no surprises each and every time — that’s a predictable mindset.
Whether you take this self-assessment test alone or with your team, take it with an open mind and be brutally honest with yourself. Your score will tell you how well your team is set up for success. Answer each of the questions either “TRUE” or “FALSE.”
Note: If you’d like to take this test online and have your score calculated for you, visit: http://www.geneca.com/mindset
| Relationship With the Business | T | F |
| I won’t start a project until the business stakeholders can clearly articulate their objectives for the project. | ||
| I am confident that the business stakeholders on my project are in sync with each other on the organization’s strategic business objectives. | ||
| I make it a priority that my entire team understands the strategic business objectives for the project. | ||
| I make sure that everyone on my team knows when their part of the project satisfies the organization’s business objectives. |
A “common vision” of success with the business goes way beyond sharing the same status reports. Predictability requires practices that get different business areas on the same page with regard to organizational goals. These goals must be clearly articulated to the delivery team and serve as their compass.
| Clearly Defined Roles & Responsibilities | T | F |
| I look to the business to define what needs to be in the project solution. | ||
| I make sure everyone on my team understands the roles and accountabilities of the project. | ||
| I hold my technical teams accountable for determining the effort to deliver the solution. | ||
| I have a single point of accountability for ensuring that the capabilities required by the business are delivered. | ||
| I have a single point of accountability for the design and performance of the technical solution. | ||
| My project managers are accountable for escalating material changes to the health of a project as soon as they know about it. |
For many organizations, clarity around roles and accountabilities is frequently an underlying source of project frustration and even failure. Even the slightest ambiguity here can hurt an entire team’s ability to perform. When responsibilities are clear, our colleagues can drive forward, deliver, and truly create a win for themselves and their team. Ensure you have individuals taking pride in their pillar of delivery: technology, functionality, quality, and leadership.
Predictability happens when the business is held accountable to “define” its need and IT is accountable for delivering a solution that supports it.
| Defining Requirements | T | F |
| I make sure that requirements are built interactively (with the business) and driven by dialog between ‘us’ and the business. | ||
| I always discuss with the business what functionality must be in the first release, using their definition of success as the key criterion. | ||
| I make sure project estimates are based on a thorough analysis of how required business capabilities are translated to technical components. | ||
| I am always crystal clear with the business about what is out of scope. | ||
| I make certain that my team is committed to the project schedule based on a clear understanding of scope. |
Before specification begins, ensure your requirements are defined. In other words, Business and IT have worked together to establish the goals of the project and agree on what is and is not in scope. The business can take ownership of the technical estimation when components are in their language and clearly tied to business outcomes.
| Managing Requirements & Changes | T | F |
| My project team manages change in terms of how it affects revisions to business functionality. | ||
| I make sure that the business stakeholders understand the relationship between change requests and the effort needed to make those changes. | ||
| I make sure that Quality Assurance and User Acceptance play a role throughout development – not just at the end of a project. |
When Business and IT have defined requirements and have worked together on estimates, they no longer feel scope management is done to them. Important decisions around change can be made smartly together.
| Metrics that Make Sense to the Business | T | F |
| I make sure that my team has a common, transparent method for communicating progress for all project stakeholders … before development begins. | ||
| I make sure that project status reports show progress in terms of the business capabilities promised. |
When the project is done, it is the business functionality that matters. So why should progress be measured and reported any other way? Agree on milestones and how progress is to be reported, before that reporting begins.
Score Interpretation: Give yourself five points for each TRUE answer and add up your score.
80+ Outstanding. You’re doing a number of great things to set your teams up for success and predictability deliver business value.
60+ Good. Refinement of your requirements processes, people roles, and metrics should eliminate any unexpected occurrences that interfere with your success.
<60 Poor. You are likely finding that your teams are not working predictably. It’s time to take a close, hard look at the obstacles that are interfering with the success of which your teams are capable.
If your score wasn’t what you hoped, the good news is that predictability is “learned behavior” and can be managed like a process with clearly defined best practices, roles and responsibilities, and performance metrics that make sense to all the players.
Take the test. Let us know if these questions stir up some new ways to improve your team’s performance.
If you’d like to refer colleagues to the test, you can pass along the link to this post, or to our Predictable Mindset test online at: http://www.geneca.com/mindset
Photo Credit: David Nicholas
Category: For Practitioners, Team Performance
Really? Are you for real? All of your requirements that you are placing on the biz in terms of getting clear requirements and clear scope is a pipe-dream, in most instances.
If the biz can get that type of clarity, then there is no reason to hire an expensive consulting firm, I can get a number of code-monkeys that will develop to spec.
The true value of a consultant is that person that can act like a chameleon and change as needed by the client. It’s not predictable, but neither is business. It’s about clear communication, not just CYA.
Thanks for the reply Jamie. When I mention placing responsibility on the business team, it isn’t to get them to huddle on their own and write detailed specs and use cases. I think that’s what you’re thinking when you read the word “requirements” here.
Requirements in this article – perhaps not as clear as I could have made it – represent business intent, when the entire team knows what “done” looks like, and what’s success is for the business. We typically call this “Requirements Definition.” You’ll notice the recurring theme in the article is business objectives, business functionality, or business capabilities. THOSE are the requirements the business does best and so I’m advocating they embrace that as defining the path for the detailed work to come.
The business will need to participate in helping the technical team get to the nitty gritty details, but until business is aligned with themselves and can articulate what success looks like, predictability is hit or miss at best. We’ve found that when business teams are given an environment for working together, to get that clarity on business value, business intent, and alignment with all the stakeholders, the corresponding technical team has a far better chance of hitting the mark.