Frequently Asked Questions

Q: What is Change Management?

A:  Perhaps best called Organizational Change Management (OCM), one definition of Change Management is the process of planning for and preparing individuals to transition from an old way of working and thinking to a new future environment.   The individuals in an organization do the work, use the new system, have to deal with different people, etc.  The goal for the organization is to help speed adoption of the change and help everyone be proficient working in the new way.

Another definition of Change Management comes from PMBoK: planning for the control of project changes to scope, budget, and time, the “triple constraints.”  There are tools and techniques such as Change Control Log, Change Control Board, and change control processes, etc.

Some people think of Change Management as system hardware and software configuration changes.  Changes to hardware and software configuration require Organizational Change Management because the people who use these systems may be affected by the changes.

Q: What is a Mind Map?

Example of a Mind Map

Example of a Mind Map

A: The term “Mind Map” was originally identified by Tony Buzan, author of The Mind Map Book.  It is a way of graphically, pictorially representing information.  It organizes thinking and uses visual and colorful notation to enhance creativity and memory.

Q: What is a project context diagram?

A: A project context diagram is a graphic representation of all the internal and external entities impacting a project.  The project context can include key individuals (e.g., project sponsor, customer, etc.), departments within an organization (e.g., Accounts Payable), government regulating bodies (e.g., FERC) – any entity that must be considered in terms of the project’s product.    Context diagrams are also used to show systems that impact a project.  For example, an SAP or other system that is core to an organizations information processing may have “bolt-on” systems that interface with SAP.  The context diagram in this case would show all systems that impact SAP.

Q: How does a context diagram benefit a project?

A: A visual representation helps to ensure that no entity is forgotten.  It also provides a graphic representation that is very helpful in explaining the impacts of a project to all those involved.

Q: What is a SME? How is a SME different from a Stakeholder? Is a SME different from a Product Owner (in an agile environment)?

A: A Subject Matter Expert (SME) is typically a person assigned to a project in order to provide specific expertise to a development team as it builds the product of the project.  The SME comes from the organization that will ultimately receive and use the product: his knowledge of how the product will be used guides the development team.   He works closely (full time or part time) with the development team and provides requirements, does testing, and supports training others in his organization.

A stakeholder is anyone who will be impacted by the project, that is, they have a stake in how the project is developed, implemented, and how the product of the project succeeds.

The Product Owner for an agile methodology project has a much broader role than most SMEs.  He is assigned full time to the team and sets long and short term goals for the project and product.  He is responsible for requirements, priorities, and budgets; he works daily with developers, accepts or rejects the product, communicates with stakeholders, and presents results to the stakeholders.

Q: What are signs and symptoms of a project that is in trouble?

  • High stakes, high risks, low confidence in team
  • Missed deadlines (poor planning, unavailable resources, wrong resources)
  • Missed requirements (ineffective analytical processes, tools, and techniques)
  • Unhappy customers, managers or executives (project does not deliver what is needed or expected, difficult time working with project team, project processes ineffective or inefficient)
  • Unhappy team members (over worked, under appreciated, no clear roles, ineffective meetings)
  • Finger pointing as to who caused the project problems
  • Repeated problems  (same as previous projects, giving the department a bad reputation)

Q: What basic project processes are needed regardless of methodology used?

A: Regardless of the methodology being used (agile or waterfall or hybrid), when deciding on the processes you need, consider a basic set including:

  • Project Initiation – how will a project get started?  Define the process for start-up of a project, formal authorization to proceed with the project based on basic information about the scope and benefits, and selection of the project manager or agile team members.
  • Project Planning – planning looks at what has to be done for the project, who has to do it, in what order it has to be done, what the schedule for delivering results is, who needs to know, what issues or things can go wrong or impede the plan and how will these be handled.  This is an iterative process in any chosen methodology.
  • Project Execution – the actual work of the project may involve specific task that have to be done in specific ways.  For example, the QA steps that a product must go through, or migration of systems into production vary in different methodologies, but they need to be defined and understood by the team.  Good processes will ensure that critical project work is executed effectively.
  • Project Control – control is on-going though a project and is needed to ensure that the right work is getting done as planned, and risks to successful completion are managed and mitigated.  Control processes include time tracking, cost tracking, issues management, change tracking, risk management, and quality review.
  • Project Closeout – at the very least, the project or phases (e.g., sprints) need to be formally closed out.  A lot happened in the course of the project, and it is extremely valuable to capture the lessons learned and improve the way in which the project was done for the next time.  This is an integral part of an agile methodology (the retrospective) and needs to be included with any approach. There may be a need for formally documenting and archiving records related to the project.  The processes to accomplish this closeout need to be defined and understood.

We are very interested in any feedback or questions you may have. Our contact information is:

MailBoxConsulting Excellence, Inc.
P.O. Box 661075
Arcadia, California 91066-1075
Office Number: 626-447-2669 (CONX)
Fax Number: 626-447-0055
 – Michelle Saykally – Barbara Ansell