with universities. Students and professors have the knowledge, research skills, and capacity to be terrific innovation partners.
Rapid Prototyping
The mantra of the start-up founder is fail fast. This term may sound confusing, because nobody wants to fail, and certainly nobody wants to fail quickly. However, founders understand that to accomplish something truly innovative, they must take risks. They also know that not every idea will be successful, and the quicker they can learn which ideas won't work, the faster they can learn from the failure, iterate, and try the next idea. Failing fast minimizes the time, money, and resources spent on bad ideas.
To accomplish failing fast or, hopefully, succeeding fast, use a prototype. A prototype is a mockup or partially working sample of the final product. I once worked with a business analyst who mocked up an entire business intelligence dashboard in Microsoft PowerPoint slides. To test the concept, we pretend clicked on buttons and then flipped to the page in the slide deck that the actual application would go to when it was completed. This desktop simulation was a quick way to test and iterate the concept before it was built. As an added benefit, the prototype served as a business requirement document for the development team.
The next step in our rapid-prototyping process was to have the development team build a working prototype in HTML. This was still a mockup, but the next step had actual users try the application on a computer. The computer mockup generated more changes, and the process was repeated until an acceptable design was found. If the business intelligence dashboard was a failure, it would be identified during prototyping, preventing us from wasting money on development.
The final step in our rapid prototyping was to build a beta version of the final product: more real than paper and HTML, but still not a full-fledged application. The beta product was released to a limited group of users, monitored, and updated as necessary.
Rapid prototyping ensures the product meets the needs of the customer even if the customer isn't exactly sure what they want in the early stages of the project. In the next chapter, we'll examine how to use these principles to evaluate your IT Department.
Note
1 7. Brent is a character in The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, and George Spafford (IT Revolution Press, 2013), https://www.goodreads.com/book/show/17255186-the-phoenix-project.
10 CIO Report Card
How is your IT Department doing?
I recommend performing an annual IT satisfaction survey of your internal customers (employees and other stakeholders in your organization). When you're a new CIO, perform the first survey immediately, then do a quick follow-up survey after six months. After establishing a baseline, survey once per year as part of your annual review process. Add customer satisfaction as one of every IT leader's objectives—not just the support teams. It's easy to get out of touch in IT; ensuring your team is aligned to their customers will help. Keep the survey short to get a better response. Make it anonymous, and ask open-ended questions to get the best possible feedback.
Grade yourself using the Laudato Hierarchy of IT Needs. To get an A, you need to achieve all four levels. See what the grades indicate in Figure 10.1.
Figure 10.1 The CIO Report Card
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
