Realistic agile selection

/in /by

Not every project is suitable for agile. To succeed with agile be sure to use sound criteria to qualify your projects as good agile candidates. Here are things to consider when establishing your agile qualification criteria:   

  • Project priority to obtain the right staff. Having the appropriate technical and business team members dedicated to the project is crucial. Agile produces results quickly and it’s time-intensive for participants. Agile requires critical business and technical team members who are vital to your business operations. So it’s important to prioritize their time so they can contribute to the project. Accepting the difficult tradeoffs between project work and operational considerations is key.
  • Appropriate breadth of knowledge. In-depth knowledge of the business and technical areas touched by the project is crucial. Business experts working closely with expert technical team members is the heart of the agile approach. The primary characteristic that makes agile methodologies agile is the method’s responsiveness to evolving needs. Knowledgeable technical and business people need to consistently reassess the project’s product, the business’s needs at a macro and micro-level, and the priority of the functions needed by the end customer. Without knowledge and availability for those assessments, the premise of agile methods crumbles.
  • Sponsor with an agile mindset. The sponsor must be willing to participate in frequent reviews of the evolving product, which are fundamental to the agile approach.  On the other hand, a sponsor who wants a linear, methodical set of objectives delivered to a pre-conceived schedule will struggle with agile project deliverables. Agile responsiveness to changing business conditions and its learning environment are very different from traditional project methods. Sponsors who resist evolutionary nature of agile create difficulties that can sink a project.
  • Ability to co-locate or simulate co-location. Agile involves deep, interactive, and sometimes challenging dialog, which produces superior outcomes. Getting the most from that dialog requires the richest environment you can create. Co-locate your project team members if possible. If you can’t, simulate co-location with the best video and audio tools you can obtain. Trying to facilitate agile dialog with sub-par communication tools is like trying to tow a big camper trailer with a lawn tractor. It just doesn’t make sense.
  • Business and technical team member synergy.  Agile methodologies require dedication from business and technical experts open to supporting new ideas and each other as individuals. You need an agile coach who understands and can manage human dynamics, and who can foster an environment where team members readily share their ideas and concerns. An agile team has to get along well to be successful.
  • A product that can be built iteratively. Agile’s best qualities come from delivering solutions in pieces while learning from each iteration. In addition to software products, other products can be produced this way as well. With a bit of creativity, facility moves, new process implementations, and even some construction projects can utilize agile methods. If you think of a way that your outcome can be produced in iterative steps, the project may be a candidate for agile (given the other items listed here, of course!)

For more about project management, see my Project Management Foundations course.

Assess your change approval criteria

/in /by

Successfully managing project scope depends on robust change management that examines the merits of each proposed scope change. Sound change management requires good change approval criteria.

Typically, change approval criteria evaluates:

  • How scope will change
  • Project costs added or deleted
  • How the schedule will change

For small projects or for very minor changes, these evaluations are enough. For more significant scope changes, consider assessing additional topics to strengthen your project’s change approval criteria.

Does the change add risk to the project? Change-related risk can vary. Adding new technology, tightening your deadlines, or forcing the business to deploy multiple changes at one time can challenge your business. Examine the risk each change brings to your project and the business.

Will more stakeholders be added? Adding stakeholders to an existing project can trigger replanning, alter success criteria, or create requirement prioritization issues. These can be very disruptive and should be carefully evaluated before approving a change.

Is additional integration involved? Increased integration of technical tools, business processes or both will add complexity to your project and expand your need for testing. This can also require additional specialized personnel on your project. Evaluate new integrations carefully.

Will multiple vendors be required? Requiring multiple vendors adds contract management time. Having vendors work together can add complexity and conflict, as vendor expectations and agendas may differ. Examining your history when working with vendors is a critical part of assessing the merit and impacts of a change.

Does the proposed change support the spirit of the project’s original scope? Ambitious or creative stakeholders can recommend project scope changes that won’t enhance or expand the original intent and business case for your project. Evaluating changes against the initial project purpose helps ensure your projects remain focused and stay within triple constraint expectations.

For more about project and change management, check out my Project Management Foundations course.