No matter what methodology you use to deliver a project managing the flow of each phase, the transition, exit and entry of phases is an essential skill project managers must be adept at. In the more structured waterfall methodology formal quality gates (also known as tollgates) may need to passed in order for the transition to be sanctioned. More dynamic methodologies whether hybrid or agile allow phases to run in parallel and transition can be smoother. Project managers must be able to manage all scenarios. Please see some general  points below before I discuss each phase separately.

• Make sure you fully understand the project methodology being used.

• If a contract stipulates certain phases need to be completed first, are dependent on one another or/and need senior management or PMO approval to transition to the next phase then as a PM you need to manage this appropriately.

• Remember waterfall structures can be rigid and lack flexibly so try not to get frustrated if the bureaucracy element is slowing down the delivery process

• Being able to project manage phase transition in structured and non structured environments is a skill in itself.

For clarity I will break a mock project down into different phases. I won’t stick to text book descriptions for phase titles as my experience tells me every company runs every project differently. For agile based projects the phase delivery is more streamlined & invariably will skip design & run development in shorter cycles known as Sprints, these will be discussed too.

Phase 1 – Procurement, Contract & Pre Planning

– Project managers may or may not be hired in time to participate in the procurement process.

– It is very helpful for the project though if PMs are included in this process as it gives them a full understanding of the need for a new system.

– If involved PMs may get to see the acceptance criteria involved for making a decision on a new system.

– These can include many variables such as functionality, costs, change management including transition from legacy systems, organisation structure, resources etc

– Procurement should include the sourcing of prospective vendors.

– Vendors should be allowed to demonstrate their systems to the prospective client 

– PMs should be involved because they can give their thoughts of which system would be easiest to implement, what methodology would work etc based on their experience 

– Clients should use a requirements matrix and use this as a basis to track how many requirements each vendor can accommodate, what may be bespoke work & incur extra costs and what simply isn’t achievable  for the vendor.

– When all this knowledge is known then the client can review and make a decision on which vendor to go with or decide further vendors need to be procured.

– Once a vendor system has been chosen contracts will need to be drawn up.

– If a PM is part of this process they can give their thoughts on how to project manage the implementation and what timeline is feasible.

– Other parts of the contract are for other stakeholders to create and complete such as legal, compliance, Human Resources, finance etc 

– When the contract is signed to all parties satisfaction some pre-planning can begin.

– This should include a mock timetable for delivery (a project on a page POAP will suffice).

– Try to understand scope of the delivery, what is in and out of scope and be aware of the scale of the delivery.

– If further resources are needed and need management approval try to get this process started.

– Any internal communications regarding the vendor decision that need to be sent, potentially across business units & markets could be sent out.

– Provisionally agree between vendor and client a starting point for the project

– Now you should be in a position to move to Phase 2 – Mobilisation & Planning.

Phase 2 – Mobilisation & Planning

– Before you sit down and begin to draft a plan you must analyse and decide what resources you need to deliver a successful project.

– Remember without an adequate project team you are setting yourself up to fail.

– Basic project resources will include business analysts, developers, testers, solution architects (may be the same as developers but also may only work on design), core project team (will normally be the subjects matter experts and proposed new system end users).

– If you believe there are gaps in the project team for example no business analyst (either available or hired) then you will have to have a talk with the sponsor and justify why you need the resource.

– You need to be aware that sponsors may not have the requisite experience to understand what resources are needed in a project so you could be facing a losing battle from the outset. 

– Also there could be budget constraints that dictate and necessitate what is needed and what is not.

– Project managers need to understand what the role description is at the start of a project as it is not standard for every project and organisation.

– The PM could be a business analyst, test manager, change manager but should never be a developer unless specifically hired for that.

– Once you are comfortable what resources will  be available to you then the mobilisation of the team can begin.

– This is where the PM informs the stakeholders of the project and what will be expected of them.

– Remember some if not all of the stakeholders may not be familiar with projects and the role of the project manager.

– After you have met the project team you can begin to draft a project plan.

– Remember this plan is draft as there is no way you can allocate all the tasks and know durations until the requirements are known.

– If you planning out phases past requirements these will need be estimate only.

– Initial plans do not need to be fancy, simple excel spreadsheet is fine.

– Once all tasks are known a more in depth & detailed plan can be created.

– Remember not all projects need structured plans, agile delivered projects are more dynamic in nature and structured projects plans will not make any sense.

– Simple & basic plans may suffice

– No matter what methodology you decide to use the initial plan should focus around requirements gathering and all the meetings and workshops needed to facilitate the production of the requirements.

– No plan can be baselined or/and signed off until requirements are fully agreed.

– Depending on the size of the deliverable a workshop timetable / tracker is worth creating 

– Understand who is required at these meetings and begin to plan out.

– In this phase the project kick off is a key meeting / workshop to have (note: I go into project kick offs in detail in a separate blog)

– During the kick off the requirements workshops can be scheduled if this has not already happened.

– To sum up, this phase is about mobilising the core project team, planning requirements gathering meetings & workshops, having a project kick off & creating a draft plan if deemed necessary.

Phase 3 – Requirement gathering**

– In my experienced opinion this is the most important phase of any project. 

– Workshops & requirements gathering meetings should take place with all key stakeholders, both client and vendor.

– It may be easier for the client to prepare all requirements first and then present to the vendor but having vendors involved in the initial process does add value too.

– A traceability matrix is useful to manage and track requirements and also online tools such as JIRA and Excel are useful tools.

– JIRA is more dynamic and if both vendor and client can accesss the same JIRA site than that is ideal. This may not be possible due to some organisations security protocols.

– Do get the key stakeholders and subject matter expert’s to sign off on all requirements.

– Do present to the internal / external vendors and get sign off from them.

– Do make sure there is no ambiguity in the requirements and that all parties interpret them in the same way.

– Align all requirements to agreed scope and signed contracts.

– Any bespoke and out of scope work should be noted and managed 

** For a more comprehensive analysis on requirements phase please see my earlier blog solely focused on requirements gathering.

Phase 4 – Design

– The design phase in theory is the bridge between the requirements and the build / development phase.

– It should outline solutions for each requirements.

– These solutions can be technical or non technical in nature but normally they will be in text format with illustrations or extracts of system functions where appropriate.

– Some project structures bypass the design phase and go straight from requirements to build.

– This can work when the majority if not all requirements are standard and/or the system being deployed does not or will not facilitate bespoke build work outside the agreed standardisation.

– This approach can work in central driven agile development teams who operate structured SPRINTs where the build takes place.

– In more waterfall & hybrid driven structures design phases do derive more benefits.

– This is because for any configuration or more importantly new build work the design team should be able to tell the stakeholders/ end users whether the requirements can be designed & built out.

– If they can’t fully commit to a requirement they can bring it to their development team for review and sign off to confirm the status.

– In design phases a design or concept type document is produced.

– This document should outline all the requirements to be built and proposed solutions, most likely in text form.

– Any requirements that are rejected or no solution can be found should be listed and reasons noted.

– Any requirements whereby the development team need to review should be noted.

– All CR (change requests) should be noted too, these could be extra out of scope requirements, bespoke build, or requirements that extra charges could be due.

– Once completed the draft design document needs to be reviewed and signed off by the design team, development team, core project team and the end users.

– The most important thing is that the development team can build out the requirements & that the core project team (end users) are happy with the proposed solution.

– Not all systems whether standard or not fit and match end user requirements, so design phases can take time to complete.

– This is why some organisations now try to adopt standardisation through universal system usage across companies and markets.

– The benefits to this approach are obvious, increases in economies of scale, cost saving, harmonious approach & standardised knowledge base to name but a few.

– However standardisation across markets can be a pipe dream.

– The reasons for this are many, local legal, regulatory, compliance, tax & business processes can be and invariably are completely different across markets.

– To align means increased pain & cost

– This tends to be solved by increased & extra design solutions necessitating the need for a design phase in the first place

– No design phase comes without its perils and sometimes having a design phase is without question completely necessary 

– I for one believe design phases are a great way for project team to understand how requirements are translated into build by designing a solution first that fits all project & stakeholder needs

Phases 5 to 9 will be released next week.