Project Practitioners > Tracking Change: Identification & Categorization - Part II

Tracking Change: Identification & Categorization - Part II

By Ann Drinkwater

Last month I talked about the three main categories of change requests – primarily from a software/product development perspective. There are numerous things we can do to help mitigate change and effectively respond to change that does occur. The bullets below outline how we can accomplish this, meet the customer’s needs the first time, and in turn help better manage our projects, clients and team:  


1)       Communicate, Communicate, Communicate. Poor communication and failure to restate needs and specifications can result in misunderstandings. Without a completely clear view of the client’s landscape, the project specs and all other pertinent details will likely falter in some fashion. Providing the client with a written account of all conversations, understanding of need and clear and thorough specifications can vastly improve all aspects of the project. Staying in close communication with the client about their needs and the potential for change may allow you to better plan and react to it when it does occur. I find that regular communication, outside of a formal meeting to discuss a specific topic or project results in more useful intelligence that can be used to properly manage current and future projects.


2)       Manage Change. A thorough understanding of the client’s business and potential volatility should be reviewed up front during project planning. Forecasting and managing change is part of the risk management plan. Change management is not a static event. Even the best communicator can encounter change. It’s how you handle and react to potential change that is important. Managing changes involves continuous awareness, being proactive in every day activities and general openness.


3)       Create an Agile Development Process, Applying Short Release Cycles. Getting things in the customer’s hand early and often will assist in ensuring the system will meet the intended goals. An agile approach, along with frequent client reviews may help ward off significant system changes and will better ensure the application will be in the client’s hands faster, before business changes do need to occur. Along with short releases and regular client checkpoints, I like to employ prototyping for features and screens that I believe involve a significant amount of risk, typically for brand new features or those that have resulted in significant pre-build discussion. Get the client involved early and keep them involved throughout.

Additionally, systems integrators and implementers should be continually developing code in modular elements that, if required, can function independently of other requirements. Understanding up front what may change allows us to plan for change in our design.


4)       Use the System as the End User. Best case scenarios and blue sky approaches to software development can lead to treachery and misunderstanding. Truly delving into the system and the client’s business, as will be done in real-world use, is necessary to identify any unnecessary quirks or oddities in design. With a thorough understanding of the client’s business and the offline processes that occur in conjunction with the software screens, I recommend working with the client to develop real-world scenarios and personally using the system to fulfill the scenarios developed. This will help identify navigation difficulties, improperly labeled buttons, or issues in workflow.


5)       Track the Origin and Source of Changes. In order to make improvements, we need to understand where we started and where we currently stand. Classifying changes, regardless of magnitude and type, is important. When changes surface, I don’t recommend making an abrupt decision on origin, but consider the history of the project and all other relevant factors that contributed to the change. Once this has been satisfied, I recommend creating classifications for changes and properly coding all changes. If there is uncertainty on how something originated, you can poll the client and the project team. Asking the client to rate the capture and accuracy of requirements and performance in delivering a product to meet their needs can be very telling. Sometimes we are too close to the details to see the real issue or what went wrong. By involving the project team, you also broaden your perspective and create a collective interest in understanding areas needing improvement.


6)       Collectively Analyze Change Request Data. With accurate reports on the frequency, timing (when in the lifecycle did the change surface), and type of requests, we are armed to make improvements. This data, just like the process involved in determining the origin of changes, should be carefully analyzed. Data patterns will help identify areas needing attention, but be sure and craft your approach to improvement in areas that you can control and measure.


7)       Determine Steps Towards Improvement. You now understand how important it is to be intimately involved with your client’s business; the ins and outs of the application that has just been built, you have controlled and categorized changes that have arisen, now you must look toward the future and ongoing, continuous improvement. In order to improve the client relationship, the product output that is being created and to reduce chaos that can result from change, it is critical to understand how to reduce change in the future. Classifying several items as usability items will not tell you much, unless you identify where the usability area was introduced, what was missing/vague from the requirements that may have contributed to the issue, the client’s involvement with this portion of the process, and any other supporting information that may identify what could be done differently next time. Working prototypes may take longer to create than static specifications, but the time spent up front can result in significant savings and client satisfaction levels later on. The complete cost, including the risk of not doing additional up front planning and communication, should be reviewed carefully.


The above tips will assist in reducing controllable change, identifying the source of changes and taking swift steps towards eliminating the same instances from reoccurring. Even after the system is released to the client, I recommend studying end user behavior, such as how they navigate, how they utilize the various screens and areas where they abandon the system. This data will help identify additional areas of improvement, outside those that have been specifically classified as changes. Project changes are typically positive improvements that surfaced after the project was defined. The key is to determine these improvements at an earlier stage, before they become engrained in the project from inception.


We are often faced with nearsighted decisions that impact the schedule and cost of the project and are too quick to forget all the effects of an improperly designed system. While we all wish for projects to be completed on time and within budget, there is nothing more frustrating than rushing a system or not taking the time up front to truly understand what is needed. A lack of complete understanding will be quite evident to the client.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

Change I find your articles very informative

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.