Home‎ > ‎

Project Management

INMAN is guided in its use of project methodology by what the customer needs. This can include:


Agile Project Management Methodology

Agile practices are published lower in this page. Here are some candidate tools that the team should consider and agree / amend in advance of starting work on the project.
Some candidates are:
  • Manage Backlog, Kanban, Tasks, Sprints and Issues with https://taiga.io/
  • Manage Acceptance Test Driven Development with lots of calculations in http://www.fitnesse.org/
  • Manage website look and feel with a tools such as https://usersnap.com/
  • Manage every aspect of user acceptance tests. From creating test cases, to actually conducting the test, to analysing the results of user acceptance tests. With engageuat, everything is stored in one place. http://www.engageuat.com/

Acceptance tests

  • capture user requirements in a directly verifiable way,
  • identify problems which unit or integration tests missed,
  • provide an overview on “how done” the system is.

user acceptance testing



Prince2 Project Management Methodology

Diagram showing PRINCE2 processes. The arrows represent flows of information.

PRINCE2 is a process-driven project management method. PRINCE2 is suited to product focussed projects in regulators and large enterprises. PRINCE2 defines 45 separate sub-processes and organizes these into eight processes as follows:

  • Starting Up a Project (SU)
  • Planning (PL)
  • Initiating a Project (IP)
  • Directing a Project (DP)
  • Controlling a Stage (CS)
  • Managing Product Delivery (MP)
  • Managing Stage Boundaries (SB)
  • Closing a Project (CP)


Information Technology Infrastructure Library

ITIL is a customizable framework of best practices that promote quality services. ITIL addresses the organizational structure and skill requirements by presenting a comprehensive set of management procedures with which an organization can manage its IT operations.

The processes identified and described within ITIL are supplier independent. ITIL v3, published in May 2007, comprises five key volumes:

  • 1. Service Strategy
  • 2. Service Design
  • 3. Service Transition
  • 4. Service Operation
  • 5. Continual Service Improvement

The Practices of Agile Project Management

Much of the PM literature today is focused on enterprise project management, portfolio management, multiple project management, and the corporate standards approach to project management. These are not domains that agile lays a claim to. Agile PM is focused on the activities found in a project with a single purpose, a definable set of outcomes, users or stakeholder that can be clearly identified, spoken to face to face. These other domains are interesting and may be appropriate for program management.

Some Agile PM practices are:

Assume Simplicity

  • It is the users who define requirements. Writing elaborate functional and system specifications to support these requirements is not an agile activity. Asking the users and stakeholders what they want in a face to face manner is agile. If a picture is worth a 1,000 words, a working piece of software, even in the form of a prototype is worth a 1,000 pictures.
  • Separation of concerns is a critical success factor for both product and project activities. Base the separations on the business architecture of the system, and then apply the technical architecture. Manage activities within the context of these separations. This creates a collection of small, interrelated projects, not one mega project.
  • Start with the simplest PM processes; verify that these processes can be deployed against the business needs. Progress to more difficult processes but always search for the simplest solutions.

Embrace Change

  • Change is part of any modern ICT project. If change is not taking place, then something is wrong, you are not talking to the right people.
  • An agile project sees changes as an advantage. Attempts to control change give away this advantage. This is frightening to many organizations, since they see change as chaos. This is not the case in agile PM. Change drives innovation, creates new understandings of the success factors, and forces all participants to ask: do I really need this step or process? Where can I see the measurable benefits of doing it this way?
  • Continuous delivery using working software enables change. Focus on vertical versus horizontal delivery (making the disk move on the first instance and every instance after that).

Enable the Next Effort

  • Use a Battle Planning paradigm for the daily project activities, its chaos at the low level and big picture strategy at the high level.
  • Focus on values for today, keeping the generation of value in the future in mind.
  • Continuously evaluate the future opportunity costs.

Incremental Change

  • Plan globally, implement locally, guided by architecture.
  • Avoid the solve global hunger solution; focus on real tangible PM methods that deliver value to the project.
  • Rapid planning in depth is not an oxymoron.

Maximize Value

  • Put working software in the hands of the users maximizes value. Discover what features have to be delivered to the people who have to do the work. Ask them face to face what do you need next?
  • Provide features in a rapid, efficient, and beneficial manner, with the minimum of resources and disruptions to the ongoing operation.
  • The stakeholders define the dimensions of value, ask them what they want, when they want it, and how much they are willing to pay for it. Ask them how they will know when it works properly.

Manage with a Purpose

  • Close all feedback loops. Measure stakeholder value and project progress continuously in real time.
  • Don't perform any PM function that can't be traced to this project's benefits. Booking further benefits for an expense today is not part of Agile PM
  • Question every action: why are we doing this? Is there value is this deliverable or activity? What would happen if we didn't perform this step?
  • Always define the outcome of an action: who benefits? How can this benefit be recognized? What is the cost of obtaining this benefit?
  • Never confuse effort with results! In the end the stakeholders only want results.

Multiple Views

  • The business process can be used to define the highest-level boundaries of the PM activities. Managing the interfaces between these processes becomes the prime role for the PM
  • Interface exchange definitions are critical for maintaining separation of concerns for the PM artifacts as well as the deliverables.
  • Inversion of control; the identification and management of the interface control points is a critical success factor. Determining who is really in charge is a full time job for the PM.

Rapid Feedback

  • Continuous engagement with the stakeholders is the primary source of feedback. Without continuous feedback, agility will fail to deliver on its promise
  • A situation room mentality must be created in which the participants are fighting the system not each other.
  • Continuous delivery of value as defined by the stakeholders is the primary behaviour of an agile project.

Working Software

  • In the end, an agile project is focused on delivering software, not the participating in the ceremonies of PM. Value is measured in how well this delivered system meets the needs of the stakeholders. The Stakeholders are the ones that get define value, not a mechanism that measures abstract progress. Save that kind of stuff for projects with frozen requirements, risk adverse stakeholders, and high ceremony management styles.
  • Continuous delivery is enhanced by using standard products with the minimum of customization.

Travel Light

  • Use technology to reduce the white space in the process and organization.
  • Move fast and light. Use experience based behaviours and high level specifications to guide the solution. Low level specifications add little sustaining value in an agile project. Working code is a measurable value to the stakeholders. It not only provides business value it is the source of feedback on what to do next.
  • Working software is also the final specification. Use written specifications to capture knowledge that will be needed independent from the working software, usually the non functional requirements.