Tailor for the Organisation Before Tailoring for the Project
A team that tailors its approach without first establishing what the organisation permits is designing in a vacuum. The design will be coherent, defensible on its own terms, and wrong in at least two places, and those places surface only when somebody with more authority than the project manager happens to look at it.
Tailoring for the organisation sits second in the sequence for a plain reason: it establishes the space the project's own tailoring has to fit inside. It also does something less obvious and worth considerably more, which is to tell the project what it does not have to build.
What the step produces
The first output is an envelope. Every project framework holds requirements of different kinds, and they are not equally movable. Some exist because a regulator, an auditor, a contract or a published standard demands them, and a project team holds no authority over any of those. Some exist because the organisation has decided, above the project, that this is how it wants work done, and those move if somebody asks. The rest exist because a colleague built a template once, and those move by decision.
Sorting a framework into those three takes a morning with the person who owns it, and the result is worth more than the morning costs because it can be reused. A project working out for itself which controls are regulatory is repeating an exercise every other project in the organisation is also doing, separately and worse.
The second output is an inventory. Organisations accumulate things a project can use: estimating data from comparable work, a pre-qualified supplier list, an accredited security pattern, a test environment with a booking process, a standard contract schedule, a lessons repository that occasionally contains something useful. A project skipping this step builds its own versions of several of them, and builds them less well, because the organisation's version has already been corrected by four previous projects.
The organisational facts that bound the approach
Section 3.4.2 of the PMBOK® Guide Eighth Edition treats tailoring for the organisation as the step that adapts an initial approach to the environment it has to run in, and four facts about an organisation do most of the bounding.
The funding cycle sets how far ahead the project must commit. An organisation allocating budget annually through a process that closes in October cannot fund an increment discovered in February without an exception, and a team planning to decide what to build as it learns needs that fact before it starts learning.
The decision calendar sets the fastest speed available. A change advisory board meeting fortnightly with a five-day submission cut-off means a decision takes up to three weeks, and no amount of pace inside the team alters it. A project cannot iterate faster than its organisation can decide.
The release and change windows set when work can actually land. Organisations with a year-end freeze, a peak trading period, a parliamentary recess or a clinical audit season have weeks in which nothing goes live, and a plan drawn without them has three invisible pauses built into it.
The resource model sets who the project can really get. In a functional organisation people are borrowed, and their line manager's priorities outrank the project's, which changes what can be committed and how far ahead. An approach assuming a stable dedicated team, inside an organisation that has never provided one, is a plan for a disappointment.
Six weeks, not two
A central government department was starting a programme to replace a citizen-facing application service. The delivery team's approach was two-week increments with a release at the end of each, which suited the work: the requirements were poorly understood, user research was available, and feedback could come back inside a fortnight.
The organisational step, done in the first week, turned up two things. The department's change advisory board met fortnightly with a five-working-day submission cut-off, and anything touching a citizen-facing service required a security review running to ten working days in a good month. The effective interval between releases was six weeks, whatever the team's internal cadence looked like.
That left the development approach alone and changed the plan considerably. The team kept two-week increments for building and learning, then grouped releases into six-week windows aligned to the board's calendar, so three increments reached users together. Demonstrations to stakeholders stayed fortnightly, because those needed nobody's approval.
The same morning turned up the second thing, which more than paid for the first. The department already held an accredited security pattern for services of that type, used by two previous programmes. Adopting it removed most of a security accreditation the team had costed at seven weeks. Six weeks of release cadence were given up and seven weeks of accreditation work were never done, and both facts were known before anybody wrote a plan.
For a PMP® candidate, read the organisation in any situation before judging the project's approach. A team blocked by a board, a freeze period or a resource model is not describing a failure of project management. It is describing an approach designed without the environment in it. A fitting response either adapts the project to the constraint or goes and asks for the constraint to move, and knowing which of those is available is the judgement. Practising where the constraint is genuinely immovable, and where it is only assumed to be, is something a structured PMP exam preparation course returns to with different organisations in the description.
The step takes a morning and needs two people in the room: whoever owns the framework, and whoever knows the calendar. Come out of it with three lists. What cannot move. What can move if asked, and who to ask. What already exists that the project can use. The third list is usually the longest, and it is the one nobody expects.
Interested in going further?
An approach designed without the organisation in it is coherent, defensible, and wrong in the places nobody looks until a gate review. Omega's PMP® Exam Preparation works through situations where the constraint sits outside the project and the plan has to account for it.
Tailoring for the organisation, and the step that follows it, are both set out in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A078: Tailoring in Project Management: What It Means and Why It Matters
A067: How Your Organisation Limits or Enables Agile Delivery
A086: Tailor for the Project You Actually Have
A079: What Should You Tailor on a Project?
A077: Tailoring in Project Management: What It Actually Means
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
