set up for success

the prime reason for variations and the negative aspect of seeking variations happens up front when there is temptation to shape the business case to get approved rather than achieve success

the business case needs to have a scope that can be achieved by the resources assigned to it

a business case should cost in the skills that are required and success should not be judged by the strength of the procurement negotations

design with vendors partners and internal subject matter experts a program based on their experience

the earliest the parties that will deliver the technology change sign into the success the more likelihood of getting success

steerco

lead by the project manager backed by the sponsor

if a partner or vendor or any other group is on the project team they are represented on the steering committee

be open and transparent on finances challenges issues and success in front of each in the room

this is the project safe space to be guarded respected and tasked with mutual success

the terms of reference needs to be written by the steering group and owned by them

location location location

the business sponsor should physically place the team a stones throw away

the space the team works in needs to feel supported and owned by the sponsor

if anyone is billing the project for most of their time they need to sit with the project

only off shore or highly specialised skills should be located away from the sponsor

hear the project moving forward and you will find that over the course of the project you will provide hundreds of moments of input

project manager

the sponsors best friend is an independent project manager that reports to the sponsor

no ties to vendors no ties to partners no ties to the organisation no ties to anyone except allegiance to the success of the sponsor and the project

don’t hear what you want to hear…hear what the project manager knows

scope budget time

the business case should aim high but it needs to be understood before starting what will be the priority of “give up”

knowing this allows planning and design methodology particularly with an agile approcah

should it be scope that varies be clear on the order of what might not happen

should it be budget is asking for more later acceptable or should the contingency be greater

if its time that can drift what’s the impact to budget and have contracts been constructed with this in mind

these three are interdependent and the team needs clarity of approach

devops

if agile is the way to go then multiple releases need embedding in business as usual

set up for the handover success by linking development knowledge with future operational ongoing maintenance

if ops are not ready or can’t keep up they will slow down stop or hinder the project flow