Every time I start a new major project or I need to learn something, I find myself trying to organize a lot of information about what I'm working on. Oftentimes there are multiple perspectives to take into account, and today I wanted to touch on a number of them that I have found time and again to be usefully distinct and complementary.
There are always at least two major perspectives to take when describing what we do when building software, which also applies to tracking progress.
One is the project perspective. What work are we doing, are we doing it on time, is everyone doing what they're supposed to. This is clasically something that we can deal with using project management tools, meaning not just software tools but also techniques, approaches, etc. Project management has a long history and well-known practices that you can leverage.
The other is the product perspective. Here we're talking about the progress on the thing we're building - is functionality built and available, are performance and reliability metrics where they need to be, etc.
I find the distinction useful when talking about a product/project because sometimes you'll make great progress on one thing (project is on time! tasks completed within deadlines!) but not on the other (the product is still more unstable or slower than what we thought it would be or wanted it to be). These are great things to go dive into and understand.
When working on a large product, I also like to separate the product view itself into two aspects. One being the end-product itself, the thing that your customers or key stakeholders care about. The other are the engineering systems that support building, testing and deploying the product.
These perspectives are useful because you will most likely be spending time on both, often from the same resource pool, and it's useful to both be clear about tradeoffs when planning, but also to make information available in a coherent manner across both, because frequently they will have the same or largely overlapping audiences - the software engineers on your team.
I was going to into more depth into organizing information for these, but this post is probably long enough as-is.
Happy project management!
Tags: management