THE ESTIMATING CYCLE

Estimates are carried out at all stages of a project, initially to help with planning. Throughout the
project, these initial estimates should be vali dated and revised to give increasing precision based on
emerging detail, the validation of assumptions, and actual measures of project perfor mance. CCM
expects early estimates to give a broad picture that is suf f icient only to support the decision on
whether to proceed. They are not expected to lay down a precise shape for the project and estimates
are expected to change as more information becomes available. Initial esti mates during feasibility will
be based on the limited information known about the project at this stage, but also on experience of
similar solutions in different projects. In foundations, as more becomes known about the detail of the
project, the estimates can be refined based on that knowledge. Later, as some of the solution starts to
be developed (during exploration and engineering), actual results and measures of velocity can be used
to refine estimates even further. Estimates are not static. They should always be reviewed at intervals
throughout a project to reassess their validity based on actual events and experience, such as further
detail being elicited, risks manifesting or going away, velocity (speed of delivery) being higher or lower
than expected, assumptions proving valid or invalid, unexpected events occurring, team availability
changing, change requests being formally raised, and so forth. In CCM, the effort and duration are fixed
so the focus is on validating what will be delivered

PROJECT VARIABLES AND CONTINGENCY

The single biggest difference in estimating for CCM projects comes from the CCM approach to project
variables. This is described in more detail elsewhere and the following summary is intended only to
explain its impact on estimating. Most projects have four factors that can vary: time, cost, fea tures, and
quality. It is not possible to fix every one of these as this would allow no contingency for the inevitable
unknowns and changes that happen during the life of a project. In traditional project management, the
features are fixed and time and cost are allowed to vary (e.g., extra resources are added or the delivery
date is postponed) so that quality may inadvertently be compromised. In a CCM project, time, cost, and
quality are fixed by the end of foundations and it is the amount of features that is allowed to vary by
applying MoSCoW prioritization. Thus contingency in a CCM project is managed within the prioritization
of the features rather than by adding extra time or cost. The impact of this on estimating is that the
overall esti mate for the work in a given time frame must include enough lower prior ity features to
provide the necessary level of contingency. This enables the guaranteed delivery of the Must Have
features to be confidently predicted. Contingency is built into the estimate and not an additional
percentage, which means driving down the Must Haves to as small a set as possible. A rule of thumb is
that Must Haves should not be more than 60 percent of project effort, but the aim is to build in enough
contingency to cover the perceived risk. For example, you may need to keep the effort in fulfilling Must
Haves to less than 50 percent where risk is very high or the project is more exploratory. Early project
estimates during feasibility and founda tions are based on less detailed information with higher levels of
risk and uncertainty and it is therefore important to take account of these factors when producing such
estimates. Assessments of project risk must be con sidered within context, for example: size of project,
experience of team, technologies, knowledge of client, locations, and so forth.

Top Tips

• Use early estimates to support decisions—don’t expect them to be definitive and unchanging. • Ensure
there are sufficient lower-priority requirements to provide contingency. • Estimates should be carried
out by, and belong to, those who will be doing the work. • Use a collaborative approach to produce
estimates. • Challenge all estimates, either by using more than one approach to give comparison or by
taking input from a range of individuals. • Estimate based on the knowledge available at the time. The
estimate will be at the same level of precision as the requirements. • Estimates should be directly
related to business requirements. • Document all estimates together with their associated scope,
assumptions, calculations, and risks. • Collect metrics to validate and improve estimates. • Learn from
experience.

ESTIMATING DURING THE LIFE CYCLE

• During Feasibility. This early in the project, the requirements are high-level and few in number, and
estimating is done top down and so the estimate cannot be precise. Its purpose is to support the busi
ness case and to give outline costs and timescales for the project. At this stage there is a high degree of
uncertainty and the estimate is by no means accurate. It can easily be half or twice the figure quoted
and so will typically be quoted as a range. Very often the prioriti zation within requirements is not
enough to allow for this level of uncertainty and it is more useful to present the estimate as a range of
values for both cost and duration; for example, a figure of between 100 and 200 days/$100,000 to
$200,000. Ideally, the lower end of this range should be enough to guarantee delivery of the Must Have
requirements. A detailed estimate for the work of the next phase (foundations) is also produced. •
During Culture Change Design. During this phase, more detail is known about the requirements as the
level of detail increases. This additional detail provides more information for estimating and reduces the
range of uncertainty in the estimate, but the estimate is still typically top down. Now the estimate is
likely to be accurate to plus or minus 50 percent, which should be covered by the prioritiza tion of the
requirements in scope. Some projects may be able to be more precise depending on the size of project,
the experience of the team, and the client. The purposes of estimating at this stage are to revisit the
business case and to produce the delivery plan. • During Exploration and Social Engineering. During
these phases the purpose of estimating is to define exactly what will be delivered within the coming
Development Time Box and to review and validate the esti mate for the whole project. There is much
more information available on which to base estimates as the requirements are being refined to a
greater level of detail, the solution is more detailed, the assumptions become validated, and actual
progress and speed of delivery are mea sured. This means that the estimates are much more accurate
and pre cise and contingency is completely covered within the prioritization of requirements. Estimates
are generally based on the tangible deliverables of the time box and are therefore created bottom-up.
As the project pro gresses through repeated development time boxes the estimates become more
accurate. The estimating workshop for a development time box takes place at the start of the time box.
The requirements need to be understood and refined to more detail so that the solution components
can be identified. These provide the basis for the time box estimate and hence the Time Box Plan. In
more exploratory development time boxes, this may happen iteratively throughout the time box, with
initial com ponent estimates based on assumptions and refined as understanding develops. Each time a
time box estimate is produced, the impact on the whole project estimate is reassessed based on the
actual rate of deliv ery. After a couple of time boxes within an increment, the team’s actual speed of
development (their velocity) should emerge. If the velocity of a team is shown to be slower or quicker
than originally envisaged, all estimates for the current increment should be revisited

T he timeboxing technique is based on the premise that it is better to have a working system with
limited functionality than to wait for months and even years to have a complete system. With this
technique, the project team can guarantee the delivery of the most important requirements on specific
dates, with other requirements scheduled for release on succes sive dates. Timeboxing is considered a
technique for delivering prioritized requirements based on the work the project team can deliver within
a set period, period! It is typically used on Agile development efforts character ized by fixed deadlines
and solutions that require frequent enhancements. According to Miranda* in 2002 (see Miranda 2011),
timeboxing requires that • Features/user requirements be grouped into functionality or com plete
subsets • Subsets be prioritized so that the team knows which requirements should be implemented
first • Each time box begins with a kickoff session and ends with a closeout session that involves
reviewing what was achieved in the time box • Work stops when the time box deadline is reached to
review progress and prepare for the next iteration (time box) • Timeboxing requires a fixed schedule
and team size • The normal completion effort is that which, in the knowledge of the estimator, has a fair
chance of being enough to develop the estimated feature while the safe estimate is that which will be
sufficient to do the work most of the time except in a few truly rare cases T he team focuses on value so
that the most valuable work is delivered after each iteration. Each iteration delivers working software
that is an addition to the previous version. Not all requirements will be imple mented, but the ones that
are implemented are the result of prioritization and perceived customer value. Finally, the project team
works with the customer to select the requirements to be included after which each identi f ied and
prioritized subset of requirements is completed for each iteration. With this technique, requirements do
not need to be fully understood before each iteration and can evolve over time. With timeboxing, scope
can be reduced but the deadline never changes. If all the deliverables can not be met within the set
time, the scope of work is reduced. Timeboxing can be combined with the MoSCoW technique for
increased effectiveness.

Time boxes are used as a form of risk management* to explicitly identify uncertain task/time
relationships (i.e., work that may easily extend past its deadline). Time constraints are often a primary
driver in planning and should not be changed without considering project or subproject critical paths.
That is, it’s usually important to meet deadlines. Risk factors for missed deadlines can include
complications upstream of the project, plan ning errors within the project, team-related issues, or faulty
execution of the plan. Upstream issues might include changes in project mission or backing/support
from management. A common planning error is inadequate task breakdown, which can lead to
underestimation of the time required to perform the work. Team-related issues can include trouble with
interteam communication, lack of expe rience or required cross-functionality, or lack of commitment,
drive, and motivation (i.e., poor team building and management). To stay on deadline, the following
actions against the triple constraints are commonly evalu ated to reduce scope: (a) drop requirements of
lower impact (the ones that will not be directly missed by the user), bearing in mind that time is the f
ixed constraint here, or (b) increase cost (e.g., add overtime or resources). T here are advantages and
disadvantages of timeboxing. The advantages include the following: • It helps prevent feature creep,
which is what happens when teams add features to software applications without scrutinizing their
relevance • It is a way of focusing on achieving what needs to be done without delay or procrastination
• It speeds up development time and ensures that the most value is delivered within the shortest
possible time • It facilitates quick feedback from customers and reduces communi cation overhead due
to the small team size T he disadvantages of timeboxing include the following: • Quality may be
sacrificed due to the high priority placed on achiev ing deadlines • It does not work well for many types
of large interventions; it’s usu ally suitable for those that can be controlled and completed within 90–
120 days or less.
Controlling a Time Box*

Every time box can be considered as beginning with a kickoff and ending with a closeout meeting. The
time box itself is comprised of main stages or iterations, such as investigation, refinement, and
consolidation, each reflecting a pass through the iterative development cycle. (See Chapter 10 on The
Iterative Development Approach for a description of the various life cycle approaches that may be
suitable for your organization at the present moment.) See Figure 12.1 for an example. Traditionally,
these constraints have been listed as scope (quality), time, and cost. These are also referred to as the
project management triangle, where each side represents a constraint. One side of the triangle cannot
be changed without affecting the others. A further refinement of the con straints is to separate product
quality or performance from scope, and turn quality into a fourth constraint.† The old adage still holds:
Do you want it good? Fast? Cheap? Pick any two and one has to suffer. You are given the options of fast,
good, and cheap, and are told to pick any two. In this instance, fast refers to the time required to deliver
the outcome, good is the quality of the final outcome, and cheap refers to the total cost of designing
and building the solution. This trilogy reflects the fact that the three properties of a culture change
initiative are interrelated, and it is not possible to optimize all three—one will always suffer. Thus, in the
final analysis you have three options: 1. Design the desired future state quickly and to a high standard,
but then it will not be done cheaply 2. Design it quickly and cheaply, but it will not be of high quality 3.
Design it cheaply and with high quality, but it will take a relatively long time

Many executives have a hard time making the trade-off between meeting the schedule and cutting back
on the deliverables, suggesting that such a thing is an erosion of quality. However, many things never
come to fruition because of the quest for perfection—for that one last requirement. The real value of
this kind of thinking is to show the complexity that is present in any culture change initiative. By acknowl
edging the limitless variety possible within the triangle, using this graphic aid can facilitate better culture
change decisions and planning to ensure alignment among team members and the outcome owners
(see Figure 12.2).

Euler diagrams consist of simple closed curves (usually circles) in the plane that depict sets. The sizes or
shapes of the curves are not important: the significance of the diagram is in how they overlap. The
spatial relation ships between the regions bounded by each curve (overlap, containment, or neither)
correspond to set-theoretic relationships (intersection, subset, and disjointedness). An Euler diagram is
a diagrammatic means of representing sets and their relationships. The first use of Eulerian circles is
commonly attributed to Swiss mathematician Leonhard Euler (1707–1783).

GETTING STARTED WITH A TIME BOX KICKOFF

T he aim of the time box kickoff is to • Review the time box objectives to gain a common understanding
of what is to be achieved. • Ensure that it is still feasible to deliver in the time box what was expected at
the Foundation stage and to replan accordingly if not. • Agree on the acceptance criteria for each
product to be delivered. If it is not possible to do this in detail at this point, such agreement can be
deferred to the end of the investigation iteration, but in this case, high-level acceptance criteria should
be agreed on until the addi tional detail is available. • Review the precise availability of team members
to participate in timeboxed activities. Remember that commitment to delivery is based on a preagreed
and fixed minimum resource levels.

• Ensure that any dependencies on teams working in other time boxes or elsewhere in the business are
understood. • Analyze risks associated with the above, and on that basis ensure an acceptable balance
of requirements of differing priorities in accor dance with the MoSCoW rules. • The kickoff should be
attended by all of the solution develop ment team members (including business champions) who will be
working in the time box, the CCM Design Team, the technical coordinator, and if needed or interested,
the business visionary.

INVESTIGATION ITERATION
T he aim of investigation is to provide a firm foundation for the work to be carried out during
refinement. For time boxes focused on Exploration activity, this will entail the solution developers and
business champions jointly investigating the detail of requirements and agreeing how these
requirements will be met as part of the evolving solution. This detailed information may be captured as
part of a formal product description or as an embellishment of the Prioritized Requirements List. Ideally,
an initial prototype of the solution will be created to demonstrate both an under standing of the
requirements and provide an early impression of the solu tion for assessment. During investigation, the
entire team should work together on the full set of requirements agreed at the kickoff. It is neces sary to
understand the full detail of all the work intended for completion in the time box if informed decisions
are to be made later on about what lower priority requirements may be dropped if necessary.

REFINEMENT ITERATION

T he aim of refinement is to complete as much of the development work as possible including testing
the deliverable(s). Development is carried out iteratively, with the primary objective being to meet the
detailed accep tance criteria previously agreed on, at the latest, by the end of Investigation period.
Refinement should start off with a quick and informal planning session, focused on determining which
members of the team will be work ing on what products and in what order. The order of the work
should be driven by the MoSCoW priorities for the time box but should be prag matically influenced by
other factors, such as a sensible development order from a technical perspective, availability of specific
resources such as specialists or business advisors, and any known cross-team dependen cies.
Refinement ends with a review with the business champions, and where appropriate, other
stakeholders. The review should determine what actions are necessary to achieve completion of the
work according to the acceptance criteria. No new work should be started after this point. Final changes
requested at this time should be carefully considered and priori tized. Significant demand for change at
this point often exposes a lack of appropriate involvement of business representatives through the time
box to date, a lesson to be learned for the future

CLOSEOUT

T he primary aim of the closeout is to record formal sign-off or accep tance of all the culture change
outcomes delivered within the time box. An important secondary aim is to determine what is to be done
about work that was initially part of the time box but was not completed. Such work may be considered
for the next time box, scheduled for some point further into the future, or even dropped from the
increment or initiative completely. It is important to avoid the situation where unfinished work simply
passes without thought into the next time box if overall timescales are to be met. A final aim of the
closeout is to look back on the time box to see if there is anything that can be learned to make the
development and/ or time box management process (TMP) more effective in the future. This could be
classed as a miniretrospective and is useful to provide informa tion for the later, formal retrospective, or
else the formal retrospective will be reliant on attendees’ abilities for recollection. If the time box has
been well controlled, this session should be very short and documented, and can be run back-to-back
with the kickoff session for the next time box. Changes are natural during any culture change initiative.
When a change occurs, it should be ranked against current priorities, and if accepted, it will be at the
expense of an already planned requirement or by changing the time box itself. With respect to defects, a
sensible strategy is to fix all critical and major defects within the time allocated at the subset in which
they are discovered, postponing minor defects to the end of the initiative and giving the customer the
choice between fixing the problems and developing additional functionality. It is obvious that
acknowledg ing from the very start that the customer might not receive everything requested requires a
very different communication, and perhaps a differ ent marketing strategy, than that of a solution that
promises to do it even when nobody believes it will do it. T he premise on which the method is based is
that businesses are better off when they know what could realistically be expected than when they are
promised the moon, the sun, and the stars, but no assurances are given with respect as to when they
could get it. To be workable for both parties, including the developer and the sponsor, a charter
(contract) must incor porate the notion that an agreed partial delivery is an acceptable, although not
preferred, outcome. A charter that offloads all risk in one of the parties would either be prohibitive or
unacceptable to the other

RELATIONSHIP WITH OTHER METHODS

Timeboxing acts as a building block in integrating with other personal time management and culture
change intelligence-building methods, with the consideration of The Chinese Room concept especially
useful for learning to think in an out-of-the-box fashion in terms of learning about different cultures*: •
The Pomodoro Technique is based on 25-minute time boxes of focused concentration separated by 5-
minute reflection and dia logue, followed by short breaks allowing the mind to recover (Nöteberg 2009)
• Andy Hunt gives timeboxing as his “T” in SMART (Schwaber 2009) • The chartering process for CCM
Teams • The daily huddle for CCM teams • The chinese room concept

THE TEAM CHARTER AND THE DAILY HUDDLE

A team charter is a document that is developed in a group setting that clarifies team direction while
establishing boundaries. It is developed early during the forming of the team. The charter should be
developed in a group session to encourage understanding and buy-in. The team charter has two
purposes. First, it serves as a source for the team members to illus trate the focus and direction of the
team. Second, it educates others (for example the organizational leaders and other work groups),
illustrating the direction of the team, as shown below. On a daily basis, the team working in a time box
gets together for a huddle meeting. Normally run by the team leader, it is a daily opportu nity to
understand progress against the chartered objectives at a detailed level and expose issues that may be
getting in the way. It is important that the daily huddle session is used to identify problems and to agree
who needs to participate in solving any problems that arise. It should not attempt to solve problems if
reaching the solution will take any more than a minute or two. The stand-up provides the primary
mechanism for the CCM team leader to track progress and exert the necessary control over the work of
the team to ensure on-time delivery of the agreed on products of the time box. A potential useful side
effect of this daily huddle is that people often end up working much longer than originally intended. If
they commit to working on a tedious task for just 30 minutes, it’s easy to get started because you have
given yourself permission to stop after only 30 minutes. But once you have overcome that inertia and
are now focused on the task, 90 minutes may pass before you feel the desire to stop (see Figure 12.3). T
he hypothetical example above shows that all the elements can come together to create a highly useful
document that boost the team’s suc cess. The charter also provides the information needed to reduce
the risk of rework, enabling the team to get it right the first time. Investing the required time to develop
a charter reduces confusion about the group’s objectives. An example is provided by Joe Mikes, CMRP,
who is a Senior.
TEAM CHARTER Team Purpose T his team will improve delivery time of finished goods. Ideally 75% of
our current late orders will be completed on time in the future. Duration and Time Commitment T he
team has been commissioned to work together for three months. The daily efforts will average 50% of
the team members’ time. Scope Activities that happen within the factory are all in scope. Decisions and
activities that are outside the physical factory that have an effect on late orders will be document but
not pur sued at this time. Members Connie Smith – Team Leader Dave Smith Susan Smith Roger Smith
Debbie Smythe – Smith Carlos Eduard Smith – Team Sponsor Desired End Result T his team will identify,
price, and prioritize activities that will change the current situation of late deliveries. The team will be
expected to drop our late finished goods delivery rate by 75%. Over the last six months there have been
82 orders on hold due to a variety of reasons. T he average per month is 14. A 75% improvement will be
equivalent to only allowing three per month on average. Supporting Resources T he team will need
access to: Production planning SME, historical records of production holds, downtime records for all
feeder departments, change manager, VP of Ops, VP of engineering, 3–5 Year Facility Strategic Plan, on-
going use of the west boardroom for a per manent working space, travel budget for the whole team to
see Winterville Plant. Reporting Plan T he team leader will provide a weekly report that outlines
participation, past-due supporting documents, availability of supporting resources, progress of primarily
tasks, documenting any past due tasks. There will also be a monthly leadership review of progress and
hurdles. Deliverables T he team will deliver a series of A3 documents outlining the current status of the
different variables, desired changes, and projected benefits that will drive down late orders. The team
will also quantify what percent of the total change each variable represents to make up the whole 75%
improvement. Links T his team effort will link to the 6-Sigma project, the CORE Safely program, and the
internal vendor alignment approach.

Consultant with Life Cycle Engineering. He has helped numerous compa nies launch and sustain
continuous improvement culture change initia tives and can be reached at [email protected]. T he
Huddle has the following characteristics*: • Is attended by all members of the development team • Runs
to a strict format in which each team member in turn describes: • What they have been doing since the
last stand-up • What they will be doing between now and the next stand-up • Any problems, risks, or
issues they are encountering that are slowing progress • Has a short and fixed duration—normally no
longer than 15 minutes (2 minutes per team member + 2 minutes is a good guide) • Is ideally held with
all participants standing in a circle in their nor mal workplace (reenforcing the desire to keep the session
short and informal) • May be attended by other roles, such as • The CCM Design Team, in order to
observe progress and pick up escalated issues • The technical coordinator, in order to keep abreast of
technical decisions and pick up escalated technical issues • Specialists, to participate as transient team
members Let’s take a moment to look at the three elements that make up a power ful huddle: vision,
unity, and clarity (see Figure 12.4). Businesses can take a page out of the football playbook and start
using the huddle in their regular CCM development process on a daily basis; this will help to begin the
culture change by creating a similar experi ence that football players experience with their team, as
Figure 12.4 illustrates. • Communicate vision. There is nothing more important in business today than
communicating the shared vision of a team and ensuring
that you support that vision regularly. Too many businesses write out a vision or value statement and
display it somewhere on the wall for all to see. Many times these posters get lost with all of the other
artwork that is hanging around the office. In order to ensure that a vision statement makes it from the
head of the employees to the heart of the employees, that statement must be communicated on a
regular basis. The huddle is a great place for the leader to speak to the existing vision, to cast new vision,
and to inspire the team to embrace the journey ahead. This can be done intentionally by using the
huddle as an opportunity to directly speak to the various aspects of the vision or by simply using vision
language throughout the huddle. • Provide clarity. Many times teams get sidelined or derailed because
there is confusion regarding the individual roles and how those roles play out to accomplishing the
vision. Having a regular time for the team to huddle provides clarity on who’s doing what and how that
responsibility is adding value to the larger picture; unclear expecta tions and unclear directives will
destroy a team and will kill produc tivity, creativity, and innovation. A way to make this efficient and
effective is to allow each team member the opportunity to share what they are working on and what
obstacles they may be experiencing. T his allows for exposure, accountability, and the opportunity for
members to help each other accomplish tasks that may require extra support. • Demonstrate unity. The
basic structure of a team assumes unity but oftentimes this unity gets lost as star performers begin to do
their part to make the business better and further their personal careers. To ensure that everyone on
the team understands the importance of the team, regular huddles where everybody speaks to their
part of the team becomes an invaluable resource. A leader can also use this time as an opportunity to
recognize those team members that have gone above and beyond in their efforts. In today’s working
environment employees enjoy recognition and often leaders take too long to recognize their star
performers. The huddle provides an opportunity for consistent recognition, sup port, and direction.
Timeboxing’s ability to circumvent perfectionism and avoid procrasti nation makes it a useful time
management technique as part of the daily huddle. A regularly scheduled team huddle can go far in your
efforts to enhance a company’s new CCM culture as long as they’re done with intentionality and design.
Don’t feel that you can simply throw some thing together at the last minute and have an impact.
Leverage this time to build your team and add value to the culture that exists within your organization.
Here are some other tips for conducting successful huddles: • Huddles have the most impact when they
are a regularly scheduled part of the day; whether that is daily, every other day, or at the least, weekly.
• Make the huddle interactive where every team member is respon sible to share with the rest of the
team. This may be difficult for some at first but it has great advantages. • Put a time limit on the huddle
and on how much each individual shares with the team. • Allow different team members to lead the
huddle and discover your up-and-coming leaders. • Create spontaneity in the huddle by having guest
speakers or special events; for instance, breakfast, watch a TED Talk, show a YouTube video, or play a
game. • Huddles are usually most effective when they are scheduled first thing in the morning. It is a
great way to discuss the various elements of the day and how the team may be impacted. • To insure
the proper communication of a thought or idea, have a talking stick or other item that gets passed
around so that the only person speaking is the person holding that item.

THE CHINESE ROOM

Most people have never heard of American philosopher John Searle’s Chinese Room.* Here is the
essence of it: Searle’s Chinese Room is a thought experiment devised as an out-of-the-box experiment
against “strong arti f icial intelligence,” the school of thought maintaining that machines can meet and
exceed human cognitive capabilities. Searle argues that, given sufficient processing horsepower, proper
architecture, and the right soft ware, a computer can not only do some of the things that the mind can
do, it can actually be a mind of its own kind, and thus enjoy all the rights and responsibilities we reserve
for humankind thinking and minds. In the Chinese Room, a person sits isolated, locked in, possessing
noth ing but the clothes on his or her back and a collection of rules written in English. These rules are
simple “if-then” statements that tell the person what to do when presented with patterns of ink on slips
of paper, which can be passed one at a time through a small slit in one wall of the room. As it turns out,
those patterns of ink on paper represent questions posed in Chinese. And as it also turns out, the person
in the room, who doesn’t know a scintilla of Chinese, can correctly answer those questions, in Chinese,
simply by manipulating the symbols according to the rules. The system works so well, in fact, that those
asking the questions believe they’re getting answers from a Chinese-speaking person, instead of an
English speaking person robotically manipulating Chinese symbols. Assuming that’s true, the question is:
Does the person sitting in the Chinese Room understand Chinese or not? Certainly, the person seems to
behave intel ligently, but does he or she have any sense of what’s really going on? T he parallels of the
Chinese Room contrasted to many modern business situations, where there are many rules about how
to enact a change but little or no understanding of what’s really going on, should be obvious. But does
all that really matter, argues Searle and others, given that the outcome is the same regardless? As
authors of this book, we would argue that it does indeed matter for understanding the concept of CCM,
if we consider a concept at the heart of computer science: GIGO, or garbage in, garbage out. GIGO
means that nonsense fed into a rule-based system will be noth ing but garbage when it exits the system.
This is one of the biggest reasons that top-down, authoritarian, because-we-say-so-change-processes
usually always fail, because they fail at changing the culture. Rules-based systems behave intelligently as
long as the inputs make sense. When those inputs— competitive changes, organizational changes,
random fluctuations in the Matrix—stop making sense, the outputs also stop making sense. It’s as if you
asked the fellow in the Chinese Room, What’s the color of funny? The answer: Why sky-blue-Swiss
cheese, of course.* For another interesting perspective involving the parallels with CCM and the Chinese
culture, see Tanaka, 2004.† A second component (or antecedent) to the Chinese Room influencer is the
idea of a paper machine, a computer implemented by a human. This idea is found in the work of the
little-known Alan Turing, the so-called father of the modern computer, who wrote about it in his report
Intelligent Machinery in 1948 (Turing 1948, 1950). Turing writes that he designed a program for a “paper
machine” to play chess. A paper machine is a kind of program, a series of simple steps like a computer
program, but written in natural language (e.g., English), and followed by a human. The human operator
of the paper chess-playing machine need not know how to play chess. All the operator does is follow the
instructions for generating moves on the chessboard. In fact, the operator need not even know that he
or she is involved in playing chess—the input and output strings, such as “N QB7” need mean nothing to
the operator of the paper machine. Turing was optimistic that computers themselves would soon be
able to exhibit apparently intelligent behavior, answering questions posed in English and carrying on
conversations. In 1950 he proposed what is now known as the Turing Test: if a computer could pass for
human in on-line chat, it should be counted as intelligent. Or, instead of becoming omnipotent or
rebooting every time a glitch comes along, you could endow the system with strong artificial intelligence
(AI), the capacity to actually understand what it’s doing and why it’s doing it, as opposed to just
following orders.* Perhaps these two methods—the Chinese Room and the paper machine—are a bit
too abstract, but this is why we focus so much on learn ing, and by extension, communication in the
culture change management process.† It is why it’s so important that everyone in your organization
understand the motives and meaning of change, as well as the method, in order to begin to understand
and change the culture and seek a better way. And that’s why, when it comes right down to it, every
change initiative is a learning initiative. Or as Edison used to say: “There is a better way, find it!”‡ (See
Figure 12.5.

PLANNING AND SCHEDULING TIME BOXES

A primary purpose of the delivery plan is to provide a schedule of the increments, and within them, the
time boxes that make up the project. The schedule should reflect the likely number and duration of each
time box in a current or imminent increment and also states, at the highest level, the planned focus for
each of those time boxes. Application of the timeboxing technique (described above) in conjunction with
the MoSCoW prioritiza tion technique will ensure on-time completion of each time box and the delivery
of a fit-for-purpose product in that time frame. If each time box completes on time, then each increment
will complete on time and thus the project as a whole will complete on time. Although they are not
controlled in the same way, an increment and a project can also be considered as time boxes because
they share the char acteristics of delivering a fit-for-purpose solution in a preset time frame. For this
reason, it is sometimes convenient to refer to these as project time boxes and increment time boxes.
When creating a schedule of time boxes, the primary driver should always be the business priority.
However, it is advisable to consider other factors when working out a delivery order. Such other factors
will include • Business and technical risk • Solution architecture and external dependencies • Ease of
implementation and the drive for an early return on investment • Availability of critical or specialist
resources • Constraints associated with business process or corporate policy • Quick wins