I have just joined a new organization which is in the process of documenting processes for different types of projects (Waterfall [SDLC), Agile and Infrastructure). My concern is that they are having the processes dictate the work. Have you experienced this and how did you handle it Saving Changes...
Sort By:
Peter WrightProgramme Manager| BAE SystemsSouthport, Merseyside, United Kingdom
I agree - the risk for that approach is that due people using such quality sticks as ISO9000 etc then you can no longer deviate form the process easily making it rigid and therefore by it's nature no longer aligned to the principles of the method (e.g. AGile, Lean).
It can be handled by putting "caveat" / breaks/decision points in the process where it is believed a hard and fast QA point (e.g. Handover from development to test) may not always be met, so the process can say that there will be a handover of the "agreed" deliverable into test and "Agreed" is decided by that project and by that team in each instance.
That way it can be flexible and meets ISO (albeit they will likely ask for evidence of an approval for each time a different approach is taken) Saving Changes...
Elizabeth HarrinDirector| RebelsGuideToPM.comLondon, England, United Kingdom
You could refer them to the updated PRINCE2 standard that now includes a section on tailoring the method to the particular project. You don't have to use PRINCE2, you just have to make them aware that even on traditionally very bureaucratic ways of managing projects the most common approach today is that you take what you need for each particular project and tailor the processes accordingly. That gives you some slack in the process to stop them dictating the work. Project managers would need to use their discretion though to apply the right level of rigour to each project. Saving Changes...
"When one door closes another door opens; but we often look so long and so regretfully upon the closed door that we do not see the ones which open for us."
