This is a summary of some high level advice I put together for a friend starting his first position in which he would lead a department. In this case it was the test engineering department for a hardware company. The group needed to improve, but the complaints from above were vague.
How do we do this better
Assume we are starting with this question. Begs the question of “what is it that we do?” and “who is the we?” Can we get those on paper? How do we know things are not as good as they could be?
What is process and what are the projects
Projects are one offs. Process guides standard ongoing operations. There are often parts of projects that can be standardized, like requirements gathering and stakeholder identification, risk labeling etc. Create some lists of what is done ongoingly and what current and recent projects, upcoming projects are. Use the concepts from “Just enough project management” by cook.
Separating people from process and roles
Rather than “Jim is the problem” take systems look at how we do things. Use the “How to measure anything” by Hubbard model for setting up roles that can be evaluated for performance. Break out the toolkit for role definition and fuzzy measures and discuss tying that into the review process.
Defining roles, responsibilities, and stakeholders
Traditional RASIC stuff. Match authority to responsibility. Identify key skills we may be missing. Identify communications channels and how they work now, where the disappointments come in. Are there others in the organization we should be talking to now, before we start thinking we can change and improve things? How do we communicate how much work is reasonable to expect from this team? How do we communicate to stakeholders who are potentially at odds about what our priorities are? Introduce the questions to answer to have an effective team from “First break all the rules” by Buckingham. They start with “Do I know what is expected of me at work?” How do we ensure the team has a “psychologically safe space” to work in where mistakes are OK. How do we tailor the process so mistakes are not repeated?
How much process
Deep dive into what roles and processes make sense for your company landscape. Look at what is realistic improvement given the political climate. We want the minimum of process and the smallest set of roles that will get us where we want to be. What is our regulatory obligation? “Checklist manifesto” by Gawande style process creation. Use the philosophy of “have a long list and make it easy to check many items as NA”.
How do we ensure we don’t forget things that often come up and have useful records and still allow smart people to make smart decisions for all the exception handling that has to occur. What are the mistakes we have repeated? What checks and balances are in place now? Which checks and balances need to be added?
Are there processes that slow us down now? Where did those come from, don’t want to have a “Chesterton’s Fence” situation. Do we need to use a Kanban approach? Is there a maximum number of projects that is reasonable for a team this size given the normal operations we also have to execute? Do we need an agile approach for parts of our projects? Are some of our projects waterfall by nature?
For the pieces that are ongoing operations, what are the bottlenecks? Take a “Theory of Constraints” by Goldratt analysis of those.
Outside perspectives
Who else should we be talking to that may be expert or at least have experience in getting to where we think we need to be? Who else might be aware of things we don’t even know we are missing? Can we get started with just a few conversations to get a sense?
Estimating projects
Are we estimating projects? Are there business decisions being made based on our estimates? Are our estimates regularly too optimistic or pessimistic? Are our estimates, or predictions of the future, being turned into commitments we then feel obligated to deliver on? Do we need process around estimation and communication of estimation? This opens up the project planning toolkit discussion. Looking at past projects, what level of data we have on effort and scope of those.
Tools
What tools do we use now for bug tracking, versioning, automated test, release, documentation, project management, document management etc. Are these the right tools for today, for where we are going?
Ensuring the improvement sticks
Begs the question of “were the changes improvements?”. Setting up feedback on this process. In Quality Systems it might be a CAPA system. How do we get to:
- Have a written plan
- Execute from the written plan
- Update the written plan
Again we want the minimum of process drag that allows a reduction in disappointments of stakeholders and a maximum of well being for the people doing the work.
4 responses to “How do we do this better?”
This information doesn’t have all the context of the original conversation I had with the person going into management, and the post covers a lot of ground. I was considering breaking up the content and expanding it out. I am curious what others think.
-isaac.
If you don’t see a “leave comment” box, I had some problems getting WordPress to allow comments without enabling third party cookies in your browser, which seems a pretty toxic way for WordPress to behave. Let me know if you don’t see a way to add a comment.
The is a bit missing from “How do we do this better? Assume we are starting with this question.” is “what we intend to improve”. IMHO you can only improve on three fronts: Time, Cost, Quality. The measurement for these are:
– Throughput: quantity delivered per unit time where deliveries are anything from test results to sales training for product introductions to added features to existing infrastructure, etc.
– Incremental dollars spent or saved on whatever is being improved. Or incremental dollars in increased revenue as a result of improvements. Or some combination.
– Either customer satisfaction improves, or return rates decrease, or team turnover lessens, defect rates diminish, etc.,
The good fast cheap paradigm. It does cover a lot of ground. It does seem that sometimes there are only two variables to be optimized against one another, and sometimes there can be four or five. But the gist of the big three “good, fast, cheap” probably comes up the most. Even in hiring a tech team, you get good people, you can get people in fast, or you can get them at lower salaries, but it is always a tradeoff. Though good could be in ability to do quality design work, or it could be good fit with the team, which then starts to look like four variables to optimize against one another.