A timeline is a a graphical representation of a linear sequence of significant events which has occurred during the accomplishment of some activity. A timetable provides a corresponding, forward-looking series of pre-arranged events, organized as a tabular list, and is used to plan and track such activities for performing and reporting on future work. Each of the events associated with these timelines and timetables may be comprised of either top-level milestones or more detailed inchstones.
read more »
The word process is an abstract concept. As a result, its meaning is often dependent upon the context in which it is used, and the mental models of those who are using the term. The dangerous part of this is that people can carry on conversations about them, and believe that they are talking about the same situations, even though they are actually discussing several, fundamentally different things. As a result, they each can think that they are communicating about the same 'process', and can go away from that conversation with the mistaken impression that they all agree on something meaningful, or all have a shared vision of what it will take to transform something. What is really going on is that consensus is typically achieved by adding ambiguity, rather than removing it.
As an example of these different 'mindsets', consider the following: read more »
The scientific method is the basis of our modern world. The three steps of the method are to establish a hypothesis, perform an experiment, and evaluate the results. The method does not guarantee a successful outcome on the first try, but has the advantage of self-correction. As a result, over time, it will (through repeated application and follow-on action) converge on a solution, if a solution can be found.
However, if core disciplines are not used throughout this experimentation (for example, by not keeping good records, or controlling the variables of your experiments), this ultimate success is not assured. Process improvement is similar, and has a set of core disciplines that must be followed for consistent performance and reliable outcomes from improvement efforts. read more »
Most improvement efforts have an element of divide and rule to them; our hope is that by carving up the territory, we can conquer it. But any top-level representation of a complex system is, by it's nature, just an abstraction. As such, it will highlight some aspects of the system, and suppresses visibility of others. We do this in order to communicate about certain behaviors or features of the system, usually by telling stories about those parts (though we often don't write those stories down). There can thus be many different top-level views of any system. It is possible for them all to be concurrently valid, useful, and consistent with one another, but this doesn't just happen automatically; it must be designed to be so.
read more »
For a few minutes, let's think of the data collection, decision-making, and status reporting involved as a person or work group performs their work, and when they need to switch from performing one set of tasks to another. Let's call this monitoring and control the 'Work Operating System' for their production (as an analog of an operating system for a computer). Like a computer system, when a person or work group switches contexts, there is overhead (in both time and energy) involved.
Psychologists describe these context switches as disrupting an individual's psychological flow, and for this reason, such changes can significantly reduce overall throughput of these work teams, whether small or large. Such context switches need to occur when one set of tasks completes, or when the Work Operating System has to respond to high-priority jobs (emergent work more important than anything else). When this occurs, the system must have sufficient resources and operating performance for accomodating this emergent work, and after it is accomplished, to continue to process both normal priority (time-critical in the short-term) jobs and lower-priority jobs (batch runs that are not immediately time-critical, but are still important over the longer term).
Processes are as difficult to develop as products, and when considering cultural issues, can be even more difficult. Unfortunately, developing or improving a process often isn't taken as seriously as a product development effort is... and as a result, the quality of the outputs from such process improvements can have very detrimental impacts on users, who have to try to muddle on, and may find themselves having to build products and fix proceses at the same time.
read more »
Many manufacturing industries have made great gains by utilizing lean principles in the factory. These principles, which have perhaps been most successfully applied in the Toyota Production System, can be summarized as follows:
read more »
Amazon has been building a virtual storage solution and a virtual computing infrastructure for a number of years, and is highly motivated to continue to evolve that capabilty for their own primary business goals (selling stuff without holding any inventory themselves).
Enter Amazon's new Mechanical Turk service offering, which promises to take these same ideas - scalable solutions, predictable costs, and quality management - and apply them to managing the workflow through and across large pools of on-demand talent. read more »
There is often quite a bit of attention given to process management in an endeavor, but this does not mean that this focus is actually producing meaningful results. How could one tell whether processes were playing a key role in an organization or not? Or is it more like a speed limit on a roadway - rules are acknowledged when in front of the courts and police, but only used as general guidance otherwise?
In the spirit of managing by facts and data, here are some questions that could support a review of evidence that could allow such a determination to be made:
One of the criticisms I've heard about CMMI from Ivar Jacobson is that just because you have a highly mature (e.g. level 5) process doesn't mean it's better than someone else's level 2 process. Of course, this begs the question of what constitutes 'better' - for a particular business purpose, what's right for one business model and scenario might be completely wrong for another. So in general, I think Ivar's right - the CMMI is a model for maturing a capabitility for continuous improvement, but you could be level 5 shop and produce a very low quantity of high quality code per period of time, when your business situation really needed a high-output, 'good-enough' approach that agile methods are so popular for producing.
read more »