I started writing code while I was in high school but my first really big professional endeavor was in software project management. I was thrown in way over my head – I was twenty-three and I was managing three different multi-million dollar development projects for Ford Motor Company all at the same time as part of my new role at Microsoft Consulting Services. I had something like thirty people working under my direction and three different customers, each with different priorities and work styles. Given such an immense challenge I don’t think I did too badly but I didn’t do great either and Microsoft eventually decided to scale back the number of projects I was leading.
I learned a lot and as a result of the experience I developed a real passion around learning how to successfully manage complex projects. Shortly after that project I becomes a certified trainer for the Microsoft Solutions Framework – a project management methodology that Microsoft had developed. I had a blast occasionally teaching classes about team models, process models, risk management and the like. Over the years I’ve followed the development of Agile, Scrum and various other homegrown project management methodologies. My interest in project management coupled with management responsibilities for teams in several different countries led to my interest and specialization in managing distributed teams and the dynamics of teams.
So that’s a little of why I care, but the purpose of this post is to share with you one of my favorite software project management tools. The various models have all evolved over time – from waterfall processes to “rapid iteration” to buzzwords like “minimum viable product”. There are pros and cons to each approach and the key to success is knowing what model works best give your particular circumstance. There are also simple but useful tools or best practices that various models offer up. One of my favorites that has stood the test of time is a simple triangle model that helps everyone get really clear about the both the realities of software project management and the priorities of the folks who are paying the bills.
The idea is simple. There are three key variables in any development project. There are the features you want to build, there are the resources (budget, people) you have to do the work and there is the time you have, i.e. yourschedule. Novices want to answer all of these questions upfront, but the unfortunate reality of project management is that you can only reliably control one of these variables. To be successful you have to prioritize these variables and decide which is non-negotiable, which is important and which is flexible.
This model is drawn using a triangle with each variable on one side. You can choose to fix the length of one side of the triangle, but the other sides then have to adjust accordingly. For example you might say I have $20k to build this app, that’s it, there is simply no more money than that. You’ve chosen to control the resources available. You then have to decide what’s second – is it more important to hit a particular date or to have a specific feature set?
The triangle makes it clear that any change – whether it be a new feature, losing a developer or moving up the schedule – requires that other trade-offs be made. New features usually require either more time, more money or more people. If you need to make a date but forget to incorporate vacation time into your planning you’re going to have to add resources or cut features. When someone ignores the need to make trade-offs the quality of the features suffer, the team starts falling apart and the schedule becomes less realistic every day.
None of this is intended to suggest that developers should not be held to commitments, it’s about helping everyone make realistic commitments. The process of developing an app or a website is full of unknowns. Will the client like the first design or insist on a second or third pass? Will the features as they are envisioned really work for users? When Apple decides all new app submissions must support 64-bit (as they did recently) suddenly developers need another day – that wasn’t a requirement when the project started. Then of course there is the app submission process itself, wherein some anonymous fellow subjectively decides whether your app is “cool enough” to be approved.
The triangle model is a simple, helpful way to ensure that everyone involved knows what is realistic and what is important. Coupled with other best practices like early customer feedback and proactive risk management it can help make your projects more successful.