Structuring portfolio investments
The dynamics of most projects wax and wane with the passage of time. As these patterns unfold, both leaders and sponsors should strive for progressive reductions in the uncertainty associated with how much the project will cost, when it will complete, and the features it will deliver. The responsibility for achieving these goals is shared between each project's leadership and the members of that project team. Unless the factors which drive this uncertainty are adequately managed through this partnership, they are likely to lead directly or indirectly to collateral impacts on other projects that are in the organization's portfolio. Read more »
Confronting entropy in managing a business
Entropy is an expression of the degree of disorder which accumulates in a system over time. Entropy has a natural tendency to increase within a particular system over time, though nailing down exactly what this means can be problematic. Conceptually, it is the amount of additional information needed to determine the exact state of a system at any particular point in time. Unfortunately, as the second law of thermodynamics postulates, it is not possible to measure this quantity in systems without impacting the system being measured.
Entropy is also an unfortunate fact of life on projects, and despite our futile desires for predictability on these projects, our interventions can be futile. Systems theory tells us that when we try to rearrange a system, the system often pushes back, and responds in unforeseen ways. For example, the more energy we inject into projects in an attempt to measure them, the harder it can become to try to determine exactly what is going on.
Project coordination and collaboration
When a particular job can be performed by a single, experienced individual, the coordination effort required to accomplish planning, decision-making, and status reporting can be kept to a minimum. But when our job instead is to develop a complex product, which must be implemented within a multi-tiered architecture, the time, effort, and skills required to perform this same coordination can quickly become substantial. Sadly, when we are assigned such jobs, we rarely give this coordination the forethought it deserves before these needs are upon us.
Jim McCarthy describes the ideal we should strive for when we perform this coordination:
Many of the challenges we face in achieving this vision come into focus when we consider a representative example of these complex products, such as when a hardware product requires sophisticated software to implement functionality. These types of complex products usually result in complex projects, and the path we must follow in coordinating all the contributors to such an effort requires competent execution, communications and interactions at many different levels. Read more »
Allocating responsibilities and authority to designated roles
Once a mission is defined for an organization, it typically must be translated into a set of expected behaviors for internal teams and members. These target behaviors must define who is expected to accomplish what, and allocate obligations for coordinating activities with other groups and individuals. These behaviors are commonly called responsibilities, and must clearly and comprehensively establish the boundaries between each of the organization's actors. This structuring of work and jobs should assure that the business outcomes desired by the organization can be achieved within the structure which the organization has adopted.
Donald Reinertsen describes why organizational boundaries must be taken into account in performing this allocation:
These responsibilities are usually grouped within containers called roles before they are assigned to individuals. These roles may be thought of as 'hats' which different individuals or teams assume at different points in a work flow so that desired outcomes are achieved. Each of these roles is given a short, unique name which allows these responsibilities to be referred to easily. Read more »
Synchronization through cycles of elaboration
Requirements are discovered, not collected. This is because thinking through and writing down all of the details required to develop and deliver a target solution usually exceeds what any one person knows or can keep in their head. To avoid falling into the abstraction trap, in which notional requirements are established that are not actionable, these details must be synthesized from multiple stakeholders and viewpoints. These details require clarity about the problem, an adequate understanding of the customer's operational concepts, and a framing and characterization of acceptable solutions for the downstream implementers.
Most real-world systems require these details to be captured across four different views: Read more »
Managing flow
Nearly all organizations have gaps between their aspirations and their actual performance. These gaps typically are the result of the structure of the organization, the environment in which the organization operates, the capabilities of individuals and infrastructure in the organization, and the interactions of these elements. The way we think about these gaps usually affects how successful we will be in addressing the underlying causes of these gaps over time.
A learning organization can incorporate these performance insights into behavioral changes quickly, efficiently, and effectively. For this learning to gain traction, an organization must design interventions which are affordable, which mitigate the constraints which arise in different situations, and which are appropriate to situations as they arise. Such changes are more likely to get traction when they emerge from the collective insights of the team members rather than mandated interventions from above. Read more »
Attention to details
Throughout my career, I have observed that different people are often attentive to and focused on different levels of conceptual refinement. These perspectives vary according to their roles on a project, their individual personalities, and their experience. I have tended to mentally categorize these individuals into one of two different types of individuals at the top and bottom of this granularity perception universe: a "Roughly right" personality type, and a "Precisely right" type. Read more »
Dynamics of Software Development
Jim McCarthy, the leader of the MS C++ Development team, provides us with a team-centric (as opposed to process or tool-centric) set of practices. The book was first released in 1995, but remains just as relevent and useful today as then. In his introduction, he reminds us that:
The real task of software management is to marshall as much intellect as possible and invest it in the activities that support the creation of the product. Intellect can take the form of abstract human qualities like creativity, cleverness, reasonableness, efficiency, and elegance. Intellect can take on other immaterial qualitieis like timeliness of availability and relevance to customer needs. The point is that to create intellectual property you need the intellectual involvement of the of the creators, and this involvement is the single hardest thing to achieve in any software development effort. Read more »
Discovering and realizing value
The pursuit of value is usually a tenuous and uncertain journey. Like quality, the characteristics we seek in this pursuit are, like beauty, often unique to the eyes and circumstances of each beholder, as well as the utility or accessibility of these characteristics. The different perspectives which all stakeholders occupy, and from which they all perform this evaluation, depend upon their unique domain expertise, lifecycle insights, and understanding of the business and operational environment they are in. Since each of these perspectives are valid within the context they are observed within, it can be quite difficult to reconcile them into a single pursuit. Yet unless this focus is achieved, precious resources can be squandered on unsustainable paths, fatal dead ends, or paradoxes. Read more »
Do enough qualified customers share a common problem?
Technologists never seem to have a shortage of ideas about possible application areas for their technologies. But unless the technologist's sponsors have deep pockets and inexhaustible patience, the enthusiasm of these technologists will usually not be sufficient by itself to fuel the required effort to bring these ideas to fruition across a product's lifecycle, since sponsor priorities and available resources wax and wane with time.
The first customers of new things are called innovators and early adopters, and they receive this label because of their pioneering spirit. Being the first to the finish line with the next new thing could enable them to exploit first mover advantages over competitors. But customers in this red zone typically must exhibit a higher than average tolerance to the uncertainties which predominate this region of technology adoption. Read more »