| There are numerous things we can do to help mitigate | | | | making an abrupt decision on origin, but consider the |
| change and effectively respond to change that does | | | | history of the project and all other relevant factors that |
| occur. The bullets below outline how we can | | | | contributed to the change. Once this has been |
| accomplish this, meet the customer's needs the first | | | | satisfied, I recommend creating classifications for |
| time, and in turn help better manage our projects, | | | | changes and properly coding all changes. If there is |
| clients and team: | | | | uncertainty on how something originated, you can poll |
| 1) Communicate, Communicate, Communicate. Poor | | | | the client and the project team. Asking the client to |
| communication and failure to restate needs and | | | | rate the capture and accuracy of requirements and |
| specifications can result in misunderstandings. Without | | | | performance in delivering a product to meet their |
| a completely clear view of the client's landscape, the | | | | needs can be very telling. Sometimes we are too |
| project specs and all other pertinent details will likely | | | | close to the details to see the real issue or what went |
| falter in some fashion. Providing the client with a written | | | | wrong. By involving the project team, you also broaden |
| account of all conversations, understanding of need | | | | your perspective and create a collective interest in |
| and clear and thorough specifications can vastly | | | | understanding areas needing improvement. |
| improve all aspects of the project. Staying in close | | | | 6) Collectively Analyze Change Request Data. With |
| communication with the client about their needs and | | | | accurate reports on the frequency, timing (when in the |
| the potential for change may allow you to better plan | | | | lifecycle did the change surface), and type of requests, |
| and react to it when it does occur. I find that regular | | | | we are armed to make improvements. This data, just |
| communication, outside of a formal meeting to discuss | | | | like the process involved in determining the origin of |
| a specific topic or project results in more useful | | | | changes, should be carefully analyzed. Data patterns |
| intelligence that can be used to properly manage | | | | will help identify areas needing attention, but be sure |
| current and future projects. | | | | and craft your approach to improvement in areas that |
| 2) Manage Change. A thorough understanding of the | | | | you can control and measure. |
| client's business and potential volatility should be | | | | 7) Determine Steps Towards Improvement. You now |
| reviewed up front during project planning. Forecasting | | | | understand how important it is to be intimately involved |
| and managing change is part of the risk management | | | | with your client's business; the ins and outs of the |
| plan. Change management is not a static event. Even | | | | application that has just been built, you have controlled |
| the best communicator can encounter change. It's how | | | | and categorized changes that have arisen, now you |
| you handle and react to potential change that is | | | | must look toward the future and ongoing, continuous |
| important. Managing changes involves continuous | | | | improvement. In order to improve the client relationship, |
| awareness, being proactive in every day activities and | | | | the product output that is being created and to reduce |
| general openness. | | | | chaos that can result from change, it is critical to |
| 3) Create an Agile Development Process, Applying | | | | understand how to reduce change in the future. |
| Short Release Cycles. Getting things in the customer's | | | | Classifying several items as usability items will not tell |
| hand early and often will assist in ensuring the system | | | | you much, unless you identify where the usability area |
| will meet the intended goals. An agile approach, along | | | | was introduced, what was missing/vague from the |
| with frequent client reviews may help ward off | | | | requirements that may have contributed to the issue, |
| significant system changes and will better ensure the | | | | the client's involvement with this portion of the process, |
| application will be in the client's hands faster, before | | | | and any other supporting information that may identify |
| business changes do need to occur. Along with short | | | | what could be done differently next time. Working |
| releases and regular client checkpoints, I like to employ | | | | prototypes may take longer to create than static |
| prototyping for features and screens that I believe | | | | specifications, but the time spent up front can result in |
| involve a significant amount of risk, typically for brand | | | | significant savings and client satisfaction levels later on. |
| new features or those that have resulted in significant | | | | The complete cost, including the risk of not doing |
| pre-build discussion. Get the client involved early and | | | | additional up front planning and communication, should |
| keep them involved throughout. | | | | be reviewed carefully. |
| Additionally, systems integrators and implementers | | | | The above tips will assist in reducing controllable |
| should be continually developing code in modular | | | | change, identifying the source of changes and taking |
| elements that, if required, can function independently of | | | | swift steps towards eliminating the same instances |
| other requirements. Understanding up front what may | | | | from reoccurring. Even after the system is released to |
| change allows us to plan for change in our design. | | | | the client, I recommend studying end user behavior, |
| 4) Use the System as the End User. Best case | | | | such as how they navigate, how they utilize the |
| scenarios and blue sky approaches to software | | | | various screens and areas where they abandon the |
| development can lead to treachery and | | | | system. This data will help identify additional areas of |
| misunderstanding. Truly delving into the system and the | | | | improvement, outside those that have been specifically |
| client's business, as will be done in real-world use, is | | | | classified as changes. Project changes are typically |
| necessary to identify any unnecessary quirks or | | | | positive improvements that surfaced after the project |
| oddities in design. With a thorough understanding of the | | | | was defined. The key is to determine these |
| client's business and the offline processes that occur in | | | | improvements at an earlier stage, before they become |
| conjunction with the software screens, I recommend | | | | ingrained in the project from inception. |
| working with the client to develop real-world scenarios | | | | We are often faced with nearsighted decisions that |
| and personally using the system to fulfill the scenarios | | | | impact the schedule and cost of the project and are |
| developed. This will help identify navigation difficulties, | | | | too quick to forget all the effects of an improperly |
| improperly labeled buttons, or issues in workflow. | | | | designed system. While we all wish for projects to be |
| 5) Track the Origin and Source of Changes. In order to | | | | completed on time and within budget, there is nothing |
| make improvements, we need to understand where | | | | more frustrating than rushing a system or not taking |
| we started and where we currently stand. Classifying | | | | the time up front to truly understand what is needed. A |
| changes, regardless of magnitude and type, is | | | | lack of complete understanding will be quite evident to |
| important. When changes surface, I don't recommend | | | | the client. |