Unit Change During Project & Organizational Growth

This post is part three of a series following the session I presented at Drupalcon Austin, entitled "Oh look, we're growing!" In this post, I'm going to explore a topic that got cut from the Drupalcon presentation but warrants exploration in a blog post: units of measurement for projects and the organization and how they change over time with growth.

Other Posts in This Series:

  1. A Formula for Healthy Project Size Compared to Organization Size
  2. Scaling Projects and Scaling the Organization
  3. Unit Change During Project & Organizational Growth
  4. Family-Sized Business Units & the Agency Holding Company Model
  5. Beware the Matrix Model?
  6. Communication Styles and Team Dynamics
  7. Agile Versus Waterfall, Once and For All
  8. Process Frameworks That Weather Growth
  9. "Why" Not "What" Documentation
  10. Project Manage the Organization
  11. Plan or Pain?

Why Mess With a Good Thing?

So you've mastered your process of estimation in hours? Great! Perhaps you've worked out the perfect project calendar with discrete tasks on specific days. Excellent. But if you want to grow, be ready to throw the units tied to your processes out the window and reinvent them continually as your business changes. Clinging to familiar units and planning methods will only tie your hands hold your projects and your organization back.

You often hear of cruising altitude levels for airplanes when discussing business, so I'll go with that same axiom. Take a $5,000, one week project. At that scale, a project manager (if they were able to find the budgeted time to allocate) could specify and track every detail down to the dollar, minute, and micro-task. Doing so might even be an effective use of time if the project is high-stakes. Let's call that the 5,000 foot level; usually you have ground visibility and can fly based on what you can see in front of you. No instruments necessary. Now take a $1 million, one year project. As project manager, there's little rationalization for tracking details to the minute and the dollar. Instead, with infinitely more moving parts and a bigger team, you'll identify overall trends to make sure the project as a whole is going in the right direction. This might equate to 30,000 feet; on most days, you're above the clouds and reliant on cockpit instruments and an autopilot system.

Depth of units and data is similar at the organization level. With a very small organization, those in charge of steering and decision-making can track every expense, conversation, and to-do. As organizations grow, leaders must rely on 30,000 foot data to make informed decisions about how to steer the organization. Getting stuck in the weeds is a trap that managers and leaders are universally at risk of falling into, and focusing on small units as a company grows only intensifies that risk. And to think, some problems with micromanagement may simply be an outcome of using units that are mis-sized to the organization!

Going back to the cruising altitude analogy, one distinct difference between air travel and growth is that with an organization, you're going to encounter multiple layers of clouds along the way, or points in growth at which the units and measurements your team previously relied upon are no longer efficient and tell the wrong story at the wrong level of detail. Interested in trying to define when those moments of change should happen? Read on for how we've approached unit change to date.

Resourcing Units

One of the critical activities to maintaining a healthy business at any size is continual definition of project teams and how your people are allocated to those teams. Often we'll refer to those people as "resources" though my main complaint with that term is the dehumanization that can occur as a result. At Metal Toad, we've held weekly resourcing meetings for years, and the intent of the meetings has changed very little: we meet to discuss which resource units are assigned to which projects for a duration of time. However, the specifics have looked different depending on the year:

  • 2011 (10 people): We met once a week to discuss project(s) for each team member each day that week, sometimes at a granular level of multiple projects per day.
  • 2012-2013 (20-25 people): We still met weekly to discuss the discrete details of the week for each team member with added emphasis on dedicated days on dedicated projects for each team member. We also added a secondary meeting with a long-term view by week for coming months for each team member.
  • 2014 (35 people): We've kept both the week-view and long-term-view meetings, but with emphasis on dedicating team members to single projects for full weeks to months at a time.
  • 2015 (50+ people?): A high-level resourcing meeting will look at allocation of projects across team units in the long-term-view, and within each team, resource allocation will occur for team members on a weekly basis.

As you can see, while we've transitioned from a smaller organization and smaller projects to larger enterprise-scale projects and a significantly larger organization, resource units have also changed. Projects resourced for split days across partial team members became dedicated days, and now often dedicated weeks with little uncertainty or project shifting. However, the burden of planning each team member even at the week level for the organization has become substantial, so we're in the middle of a shift to team units that handle multiple client projects and accounts. We'll resource those teams across our new projects, but each team will self-organize for their specifics of day-to-day project assignments and tasks.

Work Breakdown Units

As project size and complexity increases, the level of detail that we engage clients on during pre-sales, discovery, and planning has evolved. In small projects, it's easy to define most or all of the tasks necessary to complete the project up front. With bigger projects, identifying user stories and capturing the client's overall business goals becomes paramount to success because identifying all or even most of the tasks required up front gets tricky and overly time consuming. That's starting to sound rather Agile, right? With the biggest projects we've engaged on to date, the level of complexity demands a very high level view during negotiations with clients. Often statements of work define only high-level project goals up front which are defined as phases or sprints of the project. Here's a quick example that might sound familiar:

  • $10,000 project planning discussion: "We'd like to implement the Google Analytics module version 2.12 with event tracking on three home page buttons."
  • $100,000 project planning discussion: "As a site admin, I'd like to review analytics for user behavior on the home page."
  • $1,000,000 project planning discussion: "We'll need some analytics to show success of the project to our CEO."

Even with projects being planned and negotiates in potentially vague phases, ultimately the stories and tasks still end up happening throughout the course of the project. The difference is that the long-term ability to plan requires increasingly larger unit focus by both the client and vendor to successfully ship projects that meet ever-changing business goals.

Budgeting Units

Ah, the perils of projects with lots of big tasks estimated by hours. With small projects that have well-defined tasks and low uncertainty about how to accomplish those tasks, estimation by hours can be very effective. But as project size increases, specific features tend to go from day or less estimates per feature to multiple days or weeks, and the confidence level of those estimates decreases exponentially. As we've transitioned from negotiating projects based on phases and team size, we've also transitioned from estimation in hours to estimation with percentages of team members. That simple change has reduced tension significantly and kept us away from painful per-feature questioning of estimation by clients. Instead, we identify the ideal team makeup to complete the project (say two developers, a QA engineer, a creative, and a project manager) and then identify percentages of time each team member should be allocated to the project to successfully ship based on our knowledge of the overall project scope.

Timeline Units

If you've been following along, timeline units will start to sound very repetitive! As we've increased project size, we've gone from planning and tracking in hours to days to sprints (often 2-3 weeks). Project managers report on team composition per sprint, work completed per sprint, budget overview per sprint, and overall release schedule within the framework of sprints.

Client Approach Units

Finally, as project size increases, the approach your organization takes to engaging with clients needs to change accordingly. Larger projects means a bigger impact to your business if a client suddenly disappears or a project is halted. Resourcing and projecting availability of teams becomes incredibly chaotic without a longer-term view at multiple phases of projects. And not surprisingly with more dollars invested and bigger risk shouldered by the client for each individual project, per-project acquisition costs (particularly with new clients) also go up significantly. Winning large scale projects is all about building trust through building relationships, and if your organization thinks in projects as the unit for client engagement, profitability will be difficult. Instead, we've placed much greater emphasis (as many other successful firms have) on growing account programs as a whole. Within each account, we build programs consisting of project roadmaps and business strategy outlines that achieve the client's overall technology goals in the 1-5 year range. That focus has consistently led to long-term partnerships, bigger contract sizes, and decreased volatility in future resource planning.

Are there other units that you've found need to change as organizations grow? Let's discuss in the comments!

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! 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!

Date posted: July 1, 2014

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Metal Toad is an Advanced AWS Consulting Partner. Learn more about our AWS Managed Services

Have questions?