Software Engineering, Project Management, and Effectiveness
I'm a fan of simple maps to help drill in. After all, it's hard to explore the concepts if you don’t know they exist, or you don’t know what they are called. Below is a work in progress. I’m making a quick, simple map of the key activities for a some software project-relevant processes.
I’m sure I’m missing key practices and some of the names have changed. So I’m sharing it, so that folks can help share what they know, to get to a map that includes the right top level names of key practices.
As a PM (Program Manager) at Microsoft, one of the things I end up doing a lot is making lists. Lists of priorities, lists of features, lists of scenarios, lists of open issues, lists of ideas, etc.
I know a lot of people makes lists. But what's the difference that makes the difference?
I think it's three things:
As the joke goes, a plan is a lists of things you'll never do. That's what happens when you fall into analysis-paralysis or don't take action. (BTW - action and timeboxing are the cure for analysis-paralysis)
A "laundry list" is not an actionable list because it's just a random dump of things. The laundry list becomes actionable when you rank and prioritize the items, turning it into an "ordered list."
Precision is an important attribute. Precision simply means filtering out everything that's not directly relevant. I find the most valuable lists are precise. I’d rather have two precise lists, than one mixed up list. A precise list of actions, or a precise list of ideas, or a precise list of issues is a thing of beauty. It’s the elegance before the action.
There are list makers and there are list doers. Having a list is a start, but action is what really makes any list valuable. An effective list is a springboard for the right actions.
If you're an avid list maker, challenge yourself to be a skilled list doer. It's a key to making things happen, and action is the difference that makes the difference.
Here is a sketch of the mental model I use when thinking through how to address a space with prescriptive guidance:
At a high level, it’s a “stack,” and by having a model of the stack, you can choose how far up the stack to go:
One thing I didn’t explicitly show in the model, is the idea of media, such as videos and slides, and train-the-trainer material. To really get adoption, the media and train-the-trainer material help spread the word. They make it easier for raving fans to adopt and to help spread, as well as to help teach others.
Together, all these parts work to create a “platform” and an “ecosystem” for prescriptive guidance. While it’s not a hard and fast model, it has helped me both figure out the opportunities, as well as evaluate competition, and it helps me see where various types of deliverables fit into a bigger backdrop for impact.
I happened to look over to my bookshelf and noticed that I have two books that landed together by chance:
I’m a fan of “just enough.” One of my mentors liked to quiz me with the question:
“How much process do you need?”
The answer was always, “just enough.”
The question, of course, then becomes, how much is “just enough?” The answer to that is, it depends on what’s the risk? … what’s at stake? It should be commensurate to risk.
I always liked the example we gave regarding how much to invest in performance modeling:
“The time, effort, and money you invest up front in performance modeling should be proportional to project risk. For a project with significant risk, where performance is critical, you may spend more time and energy up front developing your model. For a project where performance is less of a concern, your modeling approach might be as simple as white-boarding your performance scenarios.”
Just enough not only helps you eliminate waste, in the form of unnecessary overhead, but it frees you up to better balance your other trade-offs and priorities.
I saw the Facebook privacy issue on the news. I remember somebody saying, developers should just be responsible. A common practice is to "make it work, then make it right." The problem is, you don't always get a chance to "make it right." That very much depends on what your organization values. The values define the culture.
I flashed back to our early values in patterns & practices. The thing to know about values, is that values flow down. It's what the leaders say, it's what they reward and punish. It reminded me of why our collective set of values was so important.
If you value cost …
If you value execution …
If you value learning …
If you value quality …
If you value customer-connection ...
When I look back to the values we had in patterns & practices, I see how they helped pave the way for great:
If you don't think you, your team, your company, etc. are on a path to great, check the values for clues. It’s not about having this value or that (after all, all values are … well … valuable) ... the magic is in the blend, and often the difference is in what’s missing or out of balance.
I shared some lessons learned from Bill Gates. He sets a high bar and pushes the envelope of what's possible in a lifetime. That's what's great. Thinking back, he was one of the key reasons I joined Microsoft. He'd rather be making impact, than sitting on the beach. His passion is contagious. He set the bar for “smart and gets results.”
Read lessons learned from Bill Gates and if you have a lesson or insight from Bill, be sure to share.
I’ve been thinking about execution and the lessons learned. I’ve summarized some insights and reminders.
I’ve been lucky enough to grow up with patterns & practices over the last 10 years, so I’ve been able to see what works, what doesn’t, and the difference that makes the difference.
The Vital Few Here are the vital few lessons:
20 Additional Game-Changers … Here are some additional ways to improve execution: