Thoughts on execution

A set of people working on creating a new product will at times find themselves wondering if they could have "executed" their project better. How does not go about improving execution? What rules and guidelines need to be followed to ensure that the development process is predictable and convergent?

It is important to acknowledge that the "complexity" of any project cannot be completely determined at the start. It is far more common for designers to make things up as they go about designing their products. Most designers are also "innovators" and are likely to generate "ideas" that can improve their design. These innovations also occur during the design process. Most designers would agree that their design ended up being a whole lot different from what they thought it would be at the start of the design cycle.

It is also very likely that "customers" identify changes that would benefit their end design while designers are creating a small part of it. Such changes could also come at any point in the design cycle resulting in changes in the "complexity" of the project during its development.

It is very rare for a product to be designed with just one customer or application in mind. Engineers involved in marketing a product will more often than not identify new "features" that would allow the design to be suitable for more customers and applications during the design process as well. These changes will also occur during the design cycle resulting in significant change in the complexity of the design.

It is possible for designers to limit changes that they cause to the complexity of the project by limiting the number of improvements and changes they make. Designers have very little control over changes that are caused due to new features and requirements being added from customers and marketing.

The challenge facing design groups is to manage the changing complexity of the project within the time that is available for the design process. Quite often designers will complain that the scope of the project changes too much during the design process. Interestingly they don't complain about the changes they've chosen to make. Designers need to be aware that the scope of the project is going to change quite significantly during the development process.

The design process usually has multiple steps. The first of which is to derive a block diagram to show how the design performs the required function. The second step is to create the set of blocks that are required to implement the block diagram. Ideally the last phase of the design cycle should be an optimization phase where each block is "optimized" to perform the function "optimally" in the presence of the other blocks around it.

I've observed that the "optimization" step is taken up early in the design process. This step tends to get repeated every time there is a change in the scope of the project resulting in large cycle time overruns. Premature optimization is an avoidable cause that results in poor execution. I've also noticed that some designer manage this better than others. It is common for such designers to have "automated" the "optimization" process the first time around. This allows them the flexibility to use computers rather than their time to perform the optimization. Computers are clearly better suited for this kind of work than human beings. Some designers are not particularly interested in optimization and would rather focus on methods and topologies. In general teams that have people with such an attitude tend to execute better than the other. Designers of the kind that want to optimize themselves are very likely to cause large delays in project executions. It might be useful to train such people in "automated optimization" techniques.

A variant of "premature optimization" is trying to squeeze the maximum out of a given design too early. This is so easily avoidable and quite frankly adds very little value to the design. In general this sort of "optimization" focusses on second order effects and tries to improve the design by tweaking these effects to "precision". It might be preferable to delay if not entirely avoid such tricks in designs. I find that the time it takes to achieve the "tweaks" is better used inventing a better method or design.

Designers could avoid optimization of their designs in the early part of the design cycle so as to minimize rework. It would be beneficial to use existing designs as well. Reuse in general would require lesser effort and minimize chances of errors.

In general, "high end" projects tend to be very poorly executed. Designers working on such projects tend to make many silly errors. It is quite common for such projects to be over schedule by the time the designer gets things "working" with minor shortcomings. It might be possible that high visibility and the potential for high rewards (self perceived and given by others) tends to diminish the designer's judgement. It is also noticed that management tends to take a liberal view of silly errors in such projects. You can get away with sloppy work on these kind of projects. Management should probably treat errors on face value and deal with them without being prejudiced by the "visibility" that a project has. As Scott Adams says "By Definition, risk-takers fail often. So do Morons. In practice it is difficult to sort them out". It is entirely possible that a smart designer makes dumb mistakes for which he should be held accountable. Holding the designer accountable is probably beneficial to that person in the long run. A consistent approach to dealing with "execution" errors on the part of management will go a long way in improving project execution in all kinds of projects.

It is quite common for designers to think that "pressure" resulting from high visibility causes errors. I happen to think that high "visibility" just causes such errors to be noticed. I think "pressure" in "high end" projects is a result of poor execution and not a cause. It might be useful to focus on the work that needs to be done and not be thinking about the "impact" and/or "results" while working on these kinds of projects. Designers working on high "visibility" projects should be offered a decent support structure. Management should also attempt to ensure that a modest amount of "perspective" is retained. It might be useful to reiterate that these high end projects are in the end just another project. History suggests that such projects rarely end on a high note. A lot of the "visibility" stuff just builds things up making the fall which is inevitable hard to deal with. Keeping morale up through such projects will also require intervention from management. Low morale is certainly a recipe for poor execution.

In a group of people, good "executors" are bound to exist. Management should recognize this trait in these people and ensure that they are rewarded and recognized appropriately for the same. The presence of such people is bound to have an influence on the others in the group. Most designers are capable of learning. It is only reasonable to expect that they will pick some tricks from the good "executors". A good recognition process for these designers will ensure that the group knows where to go for help on the topic of execution.

Clearly this blog is getting too long. I'll just sign off now. I don't think the thoughts presented well either. I'm still organizing my thoughts on the topic.