Erroneous beliefs about software and the process that is used to build it.
The three types of myths are management myth, customer myth and practitioner’s myth.
MANAGEMENT MYTHS
Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and improve quality. Like a drowning person who grasps at a straw, a software manager often grasps at belief in a software myth, if those beliefs will lessen the pressure (even temporarily).
Myth : You assume that the data is complete
Reality : Particularly when we look at a task’s schedule or at the task’s resource information, we assume that all information that relates to that task has also been updated. In a project schedule, almost everything is related to everything else. Missing even one task’s update information or one project resource’s update information may mean that the schedule you’re looking at is completely inaccurate.
Myth : You assume that the data has been approved
Reality : When a manager looks at project data, they make a natural assumption that the information they’re looking at has been approved by someone. Senior management won’t expect that they need to go to every individual project resource to determine that the schedule information is accurate. They expect that they can go to the project manager and have that project manager stand behind the data. Project system information is, after all, a synthesis of a lot of individual pieces of data that is analyzed and then presented in a particular way. Senior management assumes that the data that they’re looking at in their dashboard or in that management report has gone through some kind of approval process. This is particularly interesting as when we point out to management that they desire instant real-time feedback but also expect that the data has been approved in advance, that the two desires conflict.
Myth : You assume that inter-related data has been updated as well
Reality : There are numerous potential elements of related project data but here are a couple of examples. If there are interrelated project schedules where the task of one project can push the schedule of another, we assume that this has been updated too when we look at our schedule. Or, if we’re looking at a related risk management table, we assume that it is up to date when we reference it from the schedule.
Myth : If I decide to outsource the software project to a third party, I can just relax and let the firm build it.
Reality : If an organization does not understand how to manage and control software projects internally, it will invariably struggle when it out-sources software projects.
Myth : We already have a book that’s full of standards and procedures for building software. Won’t that provide my poeple with everything they need to know?
Reality : The book standards may very well exist, but is it used? Are practitioners aware of its existence? Does it reflect modern software engineering practice? Is it complete? Is it adaptable? Is it streamlined to improved time to improve time-to-delivery while still maintaining a focus on quality? In many cases, the answer to all of these questions is ‘no’.
CUSTOMER MYTHS
A customer who requests computer software may be a person at the next desk, a technical group down the hall, the marketing/sales department, or an outside company that has requested software under contract. In many cases, the customer believes myths about software because software managers and practitioners do little to correct misinformation. Myths lead to false expectations (by the customer) and, ultimately, dissatisfaction with the developer.
Myth : Net Promoter Score (NPS) is the Only Metric You Need
Reality : The Net Promoter Score (NPS) is a measure of customer advocacy that was the centerpiece of Fred Reichheld's 2006 book titled 'The Ultimate Question.' The net promoter score is calculated by taking the percent of customers who are promoters less the percent of customer who are detractors. Obviously, the higher the resulting number - the better. While the net promoter score is an effective measure of overall customer advocacy, it will not address all of your potential CEM questions.
Myth : Customer Experience is Just a New Term for Customer Service
Reality : Customer service just doesn't measure up to the customer experience. Make no mistake, customer service is as important as ever; delivering great customer service is one of the most tangible and visible methods for improving customer satisfaction. Customer service, however, represents only a small fraction of the overall customer experience. Companies that talk themselves into a false sense of accomplishment by focusing only on customer service are missing the bigger picture; customer experience encompasses much more that just customer service.
While customer service is important, focusing solely on customer service misses the mark on the bigger picture.
Myth : Each Channel Should Have A Unique Customer Experience
Reality : each channel has unique characteristics and can be used in different ways and for different purposes by the customer. Treating each channel experience as unique and independent, however, is a recipe for disaster. Each channel may indeed be different; the customer experience shouldn't be.
Myth : A Centralized Customer Database Provides a 360-degree View of the Customer
Reality : Establishing a 360-degree view of the customer has long been the holy grail of any CRM program. Many companies consolidate their multiple customer databases into a centralized customer database and declare victory. Although establishing a single customer database is foundational to a 360-degree view of the customer, a customer database alone often won't provide your company with a complete view of the customer.
Myth : A general statement of objectives is sufficient to begin writing programs – we can fill in the details later.
Reality : Although a comprehensive and stable statement of requirements is not always possible, an ambiguous “statement of objectives” is a recipe for disaster. Unambiguous requirements (usually derived iteratively) are developed only though effective and continuous communication between customer and developer.
Myth : Software requirements continually change, but change can be easily accommodate because software is flexible.
Reality : It is true that software requirements change, but the impact of change varies with the time at which it is introduced. When requirements changes are requested early before design or codes has started, the cost impact are very small.However as time passes, the cost impact grows rapidly.
PRACTITIONER'S MYTHS
Myths that are still believed by software practitioners have been fostered by over 50 years of programming culture. During the early days of software, programming was viewed as an art form. Old ways and attitudes die hard. A malpractice seen is developers are that they think they know everything and neglect the peculiarity of each problem.
Myth: Once we write the program and get it to work, our job is done.
Reality: Someone once said that the sooner you begin writing code, the longer it’ll take you to get done. Industry data indicate that between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the first time.
Myth: Until i get the program running. I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms can be applied from the inception of a project – the formal technical review. Software reviews are a “quality filter” that have been found to be more effective than testing for finding certain classes of software errors.
Myth: The only deliverable work product for a successful project is the working program.
Reality: A working program is only one part of a software configuration that includes many elements. Documentation provides a foundation for successful engineering and a more importantly, guidance for software support.
No comments:
Post a Comment