Almost 10 years ago now, I was the lead analyst on a project for a large branded consumer products manufacturer, putting in place a number of websites for various brands and portfolios. We were building the sites in Vignette, and the dev lead was fixated on the number of pages on each site and what was on each as a fundamental part of the requirements, and a core input metric for development & test estimating.
I knew that this was going to end up with sites that were built with a content management system, but would be harder to edit than if they’d been hard-coded. Fair enough for where we had deep functionality (about 3 pages on each site; most of which you could now do better with off the shelf Open Source), but the majority of the sites were templated Page Content Goes Here informational types, which would clearly grow and change over time, with new sections of information being added.
So I started reading and thinking, and looking for models to explain that this was a problem; that sites needed to be able to change over time in some areas, and that their technical underpinnings had to facilitate that. After a while, I came across a great book – Stewart Brand’s How Buildings Learn that explored exactly this topic, in the context of architecture.
This introduced me to a great model: Shearing Layers. A building consists of overlaid structural layers, and different layers are driven to change at different rates. To quote:
- This is the geographical setting, the urban location, and the legally defined lot, whose boundaries and context outlast generations of ephemeral buildings. “Site is eternal.” Duffy agrees.
- The foundation and load-bearing elements are perilous and expensive to change, so people don’t. These are the building. Structural life ranges from thirty to three hundred years (but few buildings make it past sixty for other reasons).
- Exterior surfaces now change every twenty years or so, to keep up with fashion or technology, or for wholesale repair. Recent focus on energy costs has led to re-engineered Skins that are air-tight and better-insulated.
- These are the working guts of a building: communications wiring, electrical wiring, plumbing, sprinkler systems, HVAC (heating, ventilating, and air conditioning), and moving parts like elevators and escalators. They wear out or obsolesce every seven to fifteen years. Many buildings are demolished early if their outdated systems are too deeply embedded to replace easily.
- Space Plan
- The Interior layout — where walls, ceilings, floors, and doors go. Turbulent commercial space can change every three years or. so; exceptionally quiet homes might wait thirty years.
- Chairs, desks, phones, pictures; kitchen appliances, lamps, hairbrushes; all the things that twitch around daily to monthly. Furniture is called mobilia in Italian for good reason.
And a well designed building will support this.
Now I’m far from the first to apply this in the software field, but it came to mind again the other week.
This time, the problem I was thinking through is about picking methodologies for projects.
I take it as a given that most commonly used methodologies are useful, but few are universally applicable. Therefore, you need to pick your approach to match the needs of the project (and may need to tailor from there for best fit). Already in my mind was this quote from a Linkedin discussion in the Certified PMP® group
Agile is a DEVELOPMENT Methodology and PMBoK is a PROJECT MANAGEMENT Methodology. How would you decide on the appropriate development methodology for the execution of the software phase of your project without first integrating and planning?
Glenn Deles PMP®
In many projects, you do need a hybrid approach; different layers of the project, different workstreams, different phases, may need different methodologies to work best. Insisting on a one-size-fits-all is the thinking of the wild eyed, evangelistic zealot, and I try very hard not to be That Guy. Why would you insist that an external party follow your method, as long as they meet their milestones? Why wouldn’t you use normal PMBoK procurement, financial & quality processes to manage the high levels of relationship, even if operationally it’s running in an Agile fashion? Your overall scope & timeline may be driven from a regulatory basis, and therefore have hard deadlines that need a greater degree of control to hit, but you get there with an iterative approach to the low level prioritisation, design and build.
To pick an architectural metaphor: I should be perfectly happy that the factory producing the doors for my house follow a Lean production line, as long as they arrive on-site on the right day in my waterfall plan. In fact, I should be happier, as it pushes back the last possible point of a number of decisions, from size to colour.
The very first project I ever managed were like this — although I didn’t realise this at the time.
Those projects were knowledgebases based on Kana IQ, and they were organised like this:
- Technical Requirements
- Largely defined up front, particularly with regard to infrastructure, performance and security. Launch day was certainly fixed, and we had key milestones along the way that the Steering Group needed to see us hitting.
- General Content Scope (for launch anyway)
- 90% defined up front
- Defined in an exploratory, evolutionary & iterative manner. Highly Agile; all based on direct interactions with key users and very little documented other than the actual evolving interface.
- Detailed Content Scope
- Planned in a set of weekly sprints; each week’s planning based on progress on the previous week’s focus, and prioritisation of what was left (yes, Backlog). The actual content artefacts were sourced, edited, loaded and tested in an evolving production line that had the spirit of Lean in it. Each week’s work went through a show & tell with users at the end of the sprint, which also generated input for the Backlog.
So we had a combination of Waterfall, several flavours of Agile and a distinct seasoning of Lean. And we stormed through the project, over-delivering by a factor of 50% on content in the allowed timescale. Kana said they’d never seen such a successful implementation. I’m glad I didn’t realise the potential complexity of this at the time, as it would have scared me silly, but it just all seemed natural.
So a project can consist of multiple layers, which depend on its interface with other layers, but can run independently and deliver at its speed based on potential efficiency and external factors. Sounds a lot like shearing layers to me.Recommend this post
Latest posts by Martin Burns (see all)
- Colocated Teams, Distributed Organisations - January 20, 2018
- Christmas Reading: 6 Books That Will Change Your Thinking - December 22, 2017
- Now Is Not The Time for #NoProjects - December 14, 2017