Controlling and managing change is one of the most important tasks for both the Project Manager and Systems Engineer.  Failing to do so often results in massive cost overruns, schedule slips, and failed projects.

In the previous blog “Why do my requirements keep changing?”, we talked about why requirements change.  In this blog we discuss some things you can do to help control and manage change.

Understand and mitigate the risks associated with common causes for requirement change:

1. Poorly Defined Requirement Development Process:  We need to do the best job we can upfront to define and document the requirements.  This means the organization needs to have well defined processes for developing, baselining and managing scope and requirements.  These defined processes should include:
   – templates for scope and requirements documentation
   – criteria and checklists for what needs to be done
   – characteristics of good requirements
   – defects to look out for and avoidYet, it is not enough just to have a well defined process.  Project teams need to be trained in the process, the templates, how to write good requirements, and defects to look out for. They need to make sure that requirements are needed, verifiable, and achievable.  The process needs to include both continuous and discrete requirement validation processes to help ensure the resulting requirements are defect free, clear, correct, complete, and consistent.

   Don’t fall victim to pressure of schedule to accept a really bad requirement document to work from in the design phase.  Don’t say “it’s okay, we’ll go ahead and get started with design and fix everything with change requests.”  Why?  Because the changes you will get hit with during design to fix the bad requirements you baselined in requirements will be a bear to manage going forward!

2. Ignored Requirements. If the reason for the ignored requirements is that the developers didn’t understand them, then you need to make sure that the requirements are unambiguous and verifiable.  Include rationale to help the developers understand the intent.  Other tools you can use to make sure all requirements are addressed are allocation and traceability matrices to ensure nothing is missed.
3. Immature Technology: Access the technology maturity by defining the technology readiness level (TRL) of all technologies needed to meet the stakeholder expectations.  The lower the TRL level, the higher the risk.  A general rule of thumb is never plan on using a technology at the beginning of the project that is not at least TRL 3 and have a plan to mature the technology to at least TRL 6 by the Preliminary Design Review (PDR).  To learn more about TRLs send Lou an email at info@argondigital.com and he will send you a copy of his paper “Developing Requirements for Technology Driven Projects.”
4. Unforeseen problems.  No mater what we do, change still happens.  Design for change, e.g., design it so we can make a change without having to recompile, size it for more volume or concurrent users, etc.  Rather than hard coding in a number that could change, make it a variable that can be easily defined when change is needed.  Sometimes you know change is inevitable.  You then need to write requirements to cover the expected changes.  You do this when you size the product to be bigger than the current usage because you know that in the future more users will be accessing the system.   Use a modular design approach, and include adequate margins based on a risk assessment.
5. Missing Stakeholders: At the beginning of the project, make sure that you do an assessment of all the relevant stakeholders (i.e., VIPs: those that have a vested interest, that have some degree of influence both good and bad, and those that will be participating in the development of the product in any way) that need to be involved in your project.  Identify each of the relevant stakeholders in your project plan and involve them in all the scope and requirement definition activities.
6. Overly optimistic budget or schedule:  Use best practices to estimate what it will take to develop the product based on lessons learned from similar projects.  Identify all the issues, do  risk assessment, and develop risk mitigation plans.  When defining your scope and requirements, assess all expectations and resulting requirements in terms of cost, schedule, and technology.  If something doesn’t fit, don’t include it in your project scope. Doing so increases the risk of failure.  There is always going to be some risk, but it is your responsibility to keep the risk within manageable levels.  Don’t set your self up for failure.
7. Interfaces not adequately defined.  During scope definition, develop a context diagram to identify all systems your system of interest will have to interact.  Designate a project team member to be the lead for interface management.  Make sure that the stakeholders involved in each interface are included in your stakeholder list. (see item 5 above).  For more information on managing interfaces, contact Lou at info@argondigital.com and he will send you a copy of his paper “Everything you wanted to know about interfaces, but were afraid to ask.”
8. All product lifecycle stages not addressed:  When developing use cases, stories and scenarios to define your system concepts, include all the relevant stakeholders and address all product lifecycle stages, not just operations.
9. Need Changes.  If the Need (reason why the product is needed) changes, the whole project needs to be rethought.  Remember, scope is defined within the context of the Need…  If the Need changes, you will have to redo a lot of the work you have done in order to meet the new Need.  A major reason for project failure is a failure of the team to clearly define, and agree to, the Need, goals, and objectives at the beginning of the project.  Failing to do so is like being on a ship without a rudder…….
10. Changing needs (expectations/requirements): Involve all stakeholders from the beginning and keep an open line of communication with them to avoid surprises as well as managing expectations.  If possible, avoid long development times – the risk of changing needs increases with the length of your development time.  For new or changing stakeholders ensure they understand, and agree to, the scope.  Having a baselined scope and good configuration management system in place are of utmost importance.  Any changes due to changing needs must be evaluated in terms of this scope. Ask:  Are the changes consistent with the Need (reason for the product), goals, and objectives that have already been agreed to? Is the change feasible in terms of cost, schedule, and technology? How does the change impact what has already been done? Does the change introduce additional risk to the project?

Some Advice on Change Management.

If you don’t control change, change will control you.  People have a tendency to keep coming back for  more and more.  If you are being nice and say yes to every change requested, you are going to get your project into a great deal of trouble.   Often, the person asking for the change wants it, but doesn’t want to pay more and they don’t want to wait any longer.  We know from our own experience that we can’t keep adding things without someone paying more or it taking longer than originally planned.  You don’t have to tell them no all the time, but you have to be honest with them. If you are willing to slip the schedule, if you are willing to pay more, then we can implement the change – otherwise we shouldn’t try to do it.  People might not like the answer but they will understand the risks and where you are coming from.

How to Manage Change

1. Develop and enforce a well defined requirement development and management process.  Train everyone in the process and how to write good requirements.
2. Document, baseline, and manage change to your scope to avoid scope creep.
3. Document, baseline, and manage change to your requirements to avoid requirement creep.
4. Clearly define your change management process.  Make sure everyone knows how to submit changes.
5. Avoid deferred changes and rushed changes. Deferred changes (changes approved for later implementation) may not work at the time you try to implement and may even have unintended effects.  Sometimes you can by with this, but you have to be very, very careful.  You are collecting changes against an evolving system so applying the change later may not work at all and may really mess something up.  It is often better just to table the change until you can consider doing it and then see if it still needs to be done and what is now viable.Rushed changes bypass the review process and can really mess up good systems – you may miss a major impact.  Someone will come in and say we have to make this change right now.  Rarely do changes have to be made immediately – you need to take time to assess the change. You need to be careful – people will say “it’s just a small change” or “it won’t affect anything else”  – how do they know that?
6. Develop clear criteria for change. Having criteria for change defined ahead of time allows everyone to know the rules for what type of changes they can submit and which ones not to bother with.   Three “golden rules” to guide change:
   – If it doesn’t work – fix it;
   – If it is not safe – fix it; and
   – If it is illegal or violates a code – fix it.If a change doesn’t fit into any of these three rules – don’t allow the change.  Application of these “golden rules” will go a long way in avoiding deferred changes.
7. Put in as much rigor to changes as you do for defining requirements.  Require rationale for the change and impacts of both making and not making the change.  Ensure all changes are needed, verifiable, and achievable.

In Conclusion.

Change is going to happen. As the saying goes “Change is inevitable – unless you are at a vending machine.”  You are probably going to have some change – you can’t avoid it.  Just saying no to all changes, probably will not work.  When change happens, be diligent – have a good process and have criteria for change defined.  You don’t have to approve all changes.  If someone brings in a change and you think it is a good idea but not now – let it rest until you think more about it.  Finally, you have to manage change.  You can’t get away with just letting it happen.  It really isn’t everyone else’s fault they are submitting changes if you never say no.

Comments to this blog are welcome.

If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.