I created a post earlier in the semester that discussed what elements contribute towards “good” software; one of these elements is elegant design, which is lacking in software that is “clunky” as well as bothersome to navigate and use.
A component of design that is more specific and can be more easily analyzed is the user interface, which combines aesthetics with usability. I anticipate that creating a (somewhat) functional but polished user interface will be a challenge for project teams in general, so I located an article that describes what comprises a “successful” user interface.
The article’s author highlights clarity as “the most important element of user interface design” because it must simultaneously communicate meaning and function to users. Conciseness is the next most important element; it demands that designers be careful when adding explanations or definitions to their applications to avoid clutter and confusion. Professor Hohne called for a hybrid of clarity at conciseness while reviewing our prototype during a meeting on Tuesday: “I want to see green, yellow, and red status bars, not a whole lot of extra information.” With this remark, it became clear to me that a successful user interface may actually draw on the same principles as a successful status report document.
Having read through the linked article and this post, what steps should you take to keep your prototype’s user interface clear and concise? Will the responsibility of ensuring clarity and conciseness be left to one person on your design team, or to the entire team? Lastly, how might your approach differ if you had to produce a more complex application?
In researching mentorship in the startup culture, I located a Forbes magazine article entitled “Why Entrepreneurs Need Good Mentors.” According to the author, a key benefit of having an accessible and knowledgeable mentor is that he or she can help you make good decisions more quickly; particularly in a startup situation, it is better to make a good decision sooner rather than a perfect decision later.
In addition to accessibility which permits prompt feedback, a good mentor should have “expert-level” experience, preferably as an entrepreneur, as well as a “direct yet supportive” feedback style. This latter point relates to our discussion in class about what makes a strong performance review: it is important that performance issues, whether of an employee or of an entrepreneur, be identified so that corrective action can be taken, but it is also important to make criticisms constructive. It is just as valuable to point out strengths as it is to point out weaknesses.
With the author’s points in mind, how do you feel your meetings with your mentor will guide your project’s direction? Also, what connections can you draw between your mentor’s experiences and your project?
This week in class, we are discussing the art and science of integrative thinking. To learn more about integrative thinking, I explored online for relevant articles. On The Huffington Post’s website, I located an article entitled Becoming an Integrative thinker: The Keys to Success, by Roger Martin, the academic director of an institute of the University of Toronto’s Rotman School of Management and author of the article we read for class.
Martin uses the expression “opposable minds” to explain the decision-making styles of successful leaders; he explains that when faced with options, these individuals do not choose the lesser of two evils but instead synthesize a unique option that is superior to its alternatives.
More interestingly, in my opinion, he argues that integrative thinking is a skill rather than an innate ability—one that must be nurtured to develop, as opposed to one assigned by nature.
As I thought more about the prospect of developing one’s integrative thinking skills, I began to wonder what type of practice is best. Should one focus on case studies, or should one aim to tackle real-life problems? Should one type of practice precede the other, or is a mixture of the two optimal?
Lastly, do we already practice our integrative thinking skills more regularly than one might think?
Last week in class, we discussed disruptive innovation at length, and we concluded that a key to surviving disruption is to quickly identify and respond to it. Companies that fail at either of these tasks may lose considerable market share, cash, talent, and value in the eyes of investor.
Because of our discussion, I became interested in identifying how a company can continually improve its business models to stay relevant in dynamic markets. My interest resulted in an internet search, and that search led me to an article on Bain & Company’s website entitled Repeatability: How companies create enduring businesses in a world of constant change. The article identifies a number of key principles that successful and enduring companies have in common—principles which result in what the authors call a “repeatable model” than embraces all aspects of change.
The principle that I found most interesting to examine was principle three of three: systems for closed-loop learning. These learning systems are driven by employee and customer input and are (I assert) representative of a Kaizen approach to process improvement. For a business model to be “repeatable,” it must not only encourage regular and proactive small-scale innovations, but also “develop early-warning devices that allow them to anticipate fundamental change in the marketplace.” I think that this latter point helps mitigate the need for forced, reactive changes to a company’s business model.
With the principle of closed-loop learning systems in mind, how might a start-up’s method of anticipating fundamental changes differ from a large corporation’s? What are the benefits of having a dedicated “office of restructuring” versus a distributed approach to innovation and threat identification? Why is employee empowerment important to a company’s culture of innovation?
Given that we will soon be expected to demonstrate progress on our project prototypes, I searched online for software prototyping tips. I found an article at a site called Inc about how develop a strong prototype.
One excellent recommendation made in the article was to develop a prototype with your customer in mind. This point made me recall our prototype revisions in our business analysis class two semesters ago. Our initial prototype was functional, but after reviewing it, we decided that is was more closely aligned with our project team’s needs and wants than with the customer’s. Several more revisions were needed before our prototype became more intuitive and customer-oriented.
Another point made in the article is that “it’s nearly impossible to sell a product without an elegant design.” This became particularly apparent in viewing other groups’ prototype presentations; the groups’ prototypes that made the best impression on the audience were not only functional, but also looked professional and clean. As we all know from using countless applications at work and at school, it is a chore to use poorly designed software, and poor design can seriously impair an application’s functionality.
With these observations in mind, how do you plan to balance your MIS5496 prototype’s functionality with its design? What prototyping lessons did you learn from developing applications in your business analysis class and from overseeing your BA teams in MIS3596?
In exploring project documentation techniques online, I found an excerpt from a software quality management book that illustrates the need for a balance between sufficient documentation and “over-documentation.” Some of the information was redundant to what we have learned in class; of course, certain documents are mandatory (project charter), and project scope largely dictates the extent of documentation required—wide-scoped projects need more and narrow-scoped projects need less. At the least, the author describes, documentation must perform the core functions of explaining “what to do (concept and requirements), how to do it (plan and design), how to show that it was done (test), and how to use the system (user).” However, too much documentation creates issues. The author warns that along with inducing an immediate “I’m not going to read all that!” response, over-documentation can result in inconsistencies that create confusion and damage progress.
The process for developing our ideas into interactive prototypes over the course of this semester is not as structured as it was in MIS3535. In that class, specific documents were due each week, and revisions of key documents were also expected regularly. In MIS4596, we are given more general instructions; many of the project tasks we perform—such as deciding the extent of documentation—are self-directed. Given that we have control of our projects’ direction, I expect teams’ documentation to range from minimal to very thorough.
With the hazards of over-documentation in mind, how will your team ensure that your project documentation is both manageable and thorough? How will you check for inconsistencies between documents? Lastly, which documents used in our business analysis and project management classes will you employ this semester, and which will you disregard?
Today in class, we debated the commoditization of information technology, an idea largely attributed to author Nicholas Carr. Our debate piqued my interest, so I aimed to investigate what businesspeople and technologists thought about Carr’s bold statement. My search brought me to page 99 of Carr’s personal blog, which gave me insight into just how large of a “splash” the article made in the business and technical communities. Unsurprisingly, the most fiery rebuttals came from heads of organizations centered around IT innovation (“IT ‘Is’ the Business”-type companies). Carr provides a link to an article detailing the manner in which Intel’s CEO “fires back” with an opposing viewpoint. Carr subsequently quotes Bill Gates as proclaiming that IT would not matter only if technology were perfect or simply could not be improved further; both conditions, obviously, do not describe contemporary IT.
In my exploration of the topic, I became more sure of my own stance. Particularly, I dislike Carr’s claim that IT is “no longer a source of advantage at the firm level.” Through innovation, a company can certainly gain a short-lived advantage over other firms. Perhaps what Carr more precisely means (at the risk of putting words in his mouth) is that IT alone does not result in a sustainable competitive advantage, a condition that many of us are discussing in BA4101. In other words, a single IT innovation only results in a limited and brief advantage over rivals.
To prompt further discussion, I offer this question: how can a business encourage and attain sustainable IT innovation? What types of cultural, financial, and motivating factors might promote such an endeavor?