With my presentation at the Digital PM Summit coming up on October 7th, here is post number nine in my series on organizational growth. This post ma
Process Frameworks That Weather Growth
With my presentation at this October's Digital PM Summit just a few weeks away, here is post number eight in my series that started after I first pr
With my presentation at this October's Digital PM Summit just a few weeks away, here is post number eight in my series that started after I first presented on the topic of growth at Drupalcon Austin. This post investigates how to create process frameworks that hold up throughout phases of organizational growth. It's tightly coupled with the next post in the series which will focus on creating documentation that persists.
Other Posts in This Series:
- A Formula for Healthy Project Size Compared to Organization Size
- Scaling Projects and Scaling the Organization
- Unit Change During Project & Organizational Growth
- Family-Sized Business Units & the Agency Holding Company Model
- Beware the Matrix Model?
- Communication Styles and Team Dynamics
- Agile Versus Waterfall, Once and For All
- Process Frameworks That Weather Growth
- "Why" Not "What" Documentation
- Project Manage the Organization
- Plan or Pain?
Details Rarely Persist
You'll likely agree that a detailed process that works for one project manager often does not work for the next. Procedures that work for one organization likely won't have the same impact when implemented at another. A related universal truth of growth I've had the opportunity to experience firsthand is that what works for an organization at one size likely won't work as well when the company hits the next stage of its growth.
Take Metal Toad's methods of resourcing over time. When I started, we were a small team doing daily standups, and we were able to schedule who was allocated for what on a piece of paper. Soon the paper became unmanageable with an increased team size and a spreadsheet was created. Then the team grew, and organization-wide standups no longer made sense as a method of communicating work tasks. The spreadsheet and related processes have been subsequently modified continually to accomodate additional needs. As projects grew and team members became more focused on specific projects, short-term views of resourcing became less important and long-term capacity planning became critical. Then we shifted emphasis to smaller, more nimble teams and now look at resource planning at the team unit level. That means the spreadsheet is now team-focused and deemphasizes individual team members.
It's important to note that had we attempted to resource using a software tool, we likely would have had several tool changes over the last few years or alternatively risked getting stuck in a frustrating method of resourcing that didn't match our business needs as we grew. This is partly why I've always advocated for thinking process before tools. Since I wrote that blog post, my perspective has grown a bit. Definitely identify your process before choosing the appropriate tool, but at a level further abstracted, identify your process framework before building the process that meets the specific needs of the organization in its particular stage of growth. Then build your specific processes to be robust enough to be successful, while still lightweight enough to throw away or continually reinvent. Trust me, if you grow, you're going to have to accept continual demolition and rebuilding of processes that were previously successful.
Build Process Frameworks, Not Processes
A process framework (as opposed to a process) is a bit difficult to succinctly define, but I'll liken it to the difference between a strategy and a tactic. A strategy is the high-level thought process that goes into achieving one or more objectives. Tactics are the myriad of specific actions taken to achieve those objectives. While creating strategic plans and tactical plans both require thought, a common breakdown is that strategy occurs above the shoulders (thought), while tactics occur below the shoulders (actions). Along those lines, discrete processes in your projects almost always fulfill the tactical level of completing projects, while a process framework should support the strategic project life cycle from start to finish.
Note that both process frameworks and individual processes change over time during organizational growth and can become obsolete, but the rate of change for individual processes is much higher than that of a solid framework. A process may go from a perfect fit at one stage of growth to being thrown out the window in the next, while a framework often holds up over multiple stages of growth with smaller, incremental changes.
Capture Organizational & Worldly Learning
So what should a process framework consist of in order to be useful through multiple stages of growth? In a nutshell, it should capture historical learning both internal to the organization and external within the organization's industry. It should steer those applying the framework clear of obstacles and pitfalls that have been learned in the past by those who have been through many iterations of the organization's projects. The framework should also take into account the best practices (ewwww... I hate that term but can't think of a better alternative at the moment) of industry leaders and thought leaders on process; there's no need to reinvent the wheel, but you certainly need to choose the right set of wheels for your organization!
An example of a framework at Metal Toad that has withstood the test of time with minimal changes is our stage gates, which attempt to create project checkpoints and binary yes/no pass fail criteria for some of the most critical decisions and areas of focus just about any web project. Implied in many of the stages are learnings such as:
- When the responsibility of which party takes on IA and design isn't clear, projects tend to suffer severely
- Even the most experienced SOW writer should still get a second set of eyes on their contractual documents before sending to clients
- Checking in frequently with clients on their satisfaction level and doing client retrospectives is equally important to managing the PM iron triangle for our business' health
- Project planning should be captured in specifications, architecture diagrams, and other formats appropriate to the project
While stage gates have undergone some incremental changes, the spirit and intent behind the process framework remains intact as we've gone through multiple iterations of growth!
Have favorite process frameworks that have held up well over time or individual process examples that defied the odds and survived growth? Please share!
Catch me at the Digital PM Summit
Interested in the topic of organizational growth from a PM perspective? Join me and a bunch of fellow PMs at the 2014 Digital PM Summit in Austin coming up in just a few weeks! I'll be presenting a talk similar in nature to my Drupalcon presentation and related to this blog series, but new and improved after additional months of experience and iteration. The Bureau of Digital Affairs did a great job with the inaugural 2013 event, and 2014 promises even more in store. With a great lineup of speakers, topics, and of course after-parties, you'll definitely get your monies worth. I hope to see you there!