Twenty Questions

November 18, 2007 by
Filed under: People, Project management, Teamwork 

So you have an idea for a new product, what could be a breakthrough product for your organization. You might have built pieces of this product to confirm that it is feasible, you may even have managed to get someone to invest in your idea. This is a big step, this is something that will take you to the next level with your business. How do you make it happen?

A lot of companies think that the same practices that sustained them in the early days are good enough to take them to the next level. More often than not, though, those very practices are contributing to a great deal of risk and uncertainty, and are actually holding them back from making that leap. For something as important as a breakthrough project, you will likely need to consider a breakthrough approach to deal with the scaled complexity and risk, and likely larger team that you are getting into.

Independent of any specific approach, there are a number of questions you need to seriously ask yourself, and be able to answer about your new product as specifically as you can. While these can be useful for the run-of-the-mill things you have been doing, these are absolutely critical when taking on something so new and important. Indeed, you should answer these questions first, then use this understanding as a means of selecting which approach would be most effective to drive the project, not the other way around.

The first cluster of questions helps you understand the bounding box of the proposed product. Set your goals so you have a shot at meeting them. Can you identify a specific vision for the product, including who the primary beneficiary is, the key needs you intend to address, and how this product is differentiated from the competition? Can you quantify the expected value to the end-user or purchaser of the product, as well as the value you expect to gain from developing the product? Can you put a clear box around the product and specifically identify the external entities the system will need to talk to? Are there any constraints in terms of time, resources, scope or quality that you need to adhere to for this project? Perhaps more importantly, as almost no group agrees on this, which of those four dimensions is most important for you, and what are your degrees of freedom in the other areas? What are the risks that could impact this project, and the opportunities that could make life easier for you?

Now you can start planning how to gain an understanding of what you need to build. Can you identify all the different classes of stakeholders that will either influence or be influenced by this product? Here, think about the internal development teams and external regulatory bodies as well as the traditional user-stakeholder. Can you identify someone to reasonably represent every one of these stakeholders, as well as someone to represent those external systems the product will be talking to? Are there specific technologies that you intend to include, and are you sure you are not over constraining the solution by selecting these technologies so early? Looking at the proposed product, can you break it down to identify which analysis techniques are the most appropriate to understand the specific elements, and which people needs to be involved in these analyses? You will probably want to dive into use cases for some elements, GUI and report mockups for all user interface elements, a deep data analysis of the essential information moving within the system and across to outside systems, and likely a host of other approaches to complement these as well.

If you have done all this, you understand the shape of the product and the effort needed to tackle the analysis to really understand the product, but you have not yet done that analysis, and you are not nearly ready to focus on the implementation. While there may have been spot prototypes to validate concepts, to dive more deeply into implementation if you have not used any opportunity for deeper understanding is to forge ahead with higher risk, and usually higher cost. The effort to this point is strategic thinking that will take on the order of hours, and to forge ahead without being able to express the answers to these questions is foolhardy. Unless, of course, the product is not that important to your business.

Now, take all those analysis techniques and the people required and actually perform those analyses.

Make all the decisions you can with the right people present, rather than leaving it up to individuals downstream, which would come at a much higher cost. There are more questions here. Are you working to understand the quality of the system you intend to build along with the functionality, all in quantified terms? Are there gaps that have been identified in the analysis that might require different approaches or prototypes for you to get your answer? Are you looking at the software component on its own, or the bigger picture that might include hardware, training, support and maintenance? Are you checking all of these analyses against each for consistency and to spot other holes? If you are in an outsourcing situation or have a team that doesn’t know the domain well, should you drill down to detailed functional requirements? Have you done enough analysis so that the risk of diving into implementation is lower than the risk of running out of time because of too much analysis? If you look at your history and take into account all the downstream effort because of weak analysis in the past, you will likely find that more analysis makes a lot of sense.

Just a few more questions to close out. Are all your original assumptions about that first set of questions still valid? Do you have an arrangement so that as changes occur downstream, you can reflect against all this information you have gathered to confirm that the change makes sense, and keep all this information current and consistent? Have you captured all of this information in a form that allows anyone involved with the project to locate it, and debate change based on that common line in the sand? Finally, after you have done all this and recognized that it is not all that onerous compared to the challenges you likely face on your projects without dealing with these questions, doesn’t it make sense to do this for all projects?

Regardless of the nature of the project, walk through these questions with your group, and you will probably discover key points that otherwise could pop up much later, at a far greater cost. For the smaller, lower risk projects, an informal session of a couple of hours can cover these, and away you go. For the larger, mission critical projects, the greater time investment is quite worthwhile. If it is a project that you are banking on to transform your business, you had better take this stuff seriously. – JB

If you enjoyed this post, make sure you subscribe to my RSS feed!


Feel free to leave a comment...

  • Search by Topic

  • What’s Happening

    September, 2017 – A workshop series to help you develop resilience in the workplace and in your life!

    Next open enrolment sessions start soon – contact us to get involved!

  • On The Road Again

    Jim frequently travels across Western Canada for engagements, and welcomes opportunities to meet, run a workshop, Diagnostic or Lunch and Learn session.

    Contact Jim if you would like to connect around any of the upcoming dates:

    • September 19-21, 2017 – Winnipeg, MB
    • October 4-5, 2017 – Regina, SK
    • October 21-22, 2017 – Winnipeg, MB
    • November 1-2, 2017 – Saskatoon, SK
    • November 27-28, 2017 – Edmonton, AB
    • February 10-11, 2018 – Edmonton, AB
  • What People are Saying

    We found the diagnostic very effective in providing a way for our teams to express their views on areas that we need to improve. At the same time, seeing where we were doing relatively well offered some great perspective and encouragement.

    — Michael Nienhuis, VP Operations, Class Software Solutions Ltd.