This Focused Performance Weblog started life as a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective, but is in the process of evolving towards primary content on interactive and mobile marketing. Think of it as about Focusing marketing messages for enhanced Performance. If you are on an archive page, current postings are found here.

Monday, June 30, 2003

Life Cycle of a Silver Bullet -- A parable by Sarah Sheard of the Software Development Consortium pointing out various fallacies of blindly following the latest big idea, including...

"Only by really looking at your company's problems can you solve them. Other people's strategies worked for them because the strategies were made for them. If you want to make real improvements, you have to do the work of determining your business problems and applying methods that make sense to fix them."

The idea of benchmarking such efforts is not new to readers of this weblog or of other pages of this site.

As Sheard points out, as processes and approaches are copied over and over again, they lose fidelity to the original, just as a copy of a copy of a copy does on paper. As the clarity of paper copies suffer, the potency of approaches suffer, especially when attempts are made to match it to the inevitable different starting points. There is no such thing as a canned solution -- each situation searching for improvement must take a clean look at where they are at, and determine for themselves the constraint that limits their performance, the culture that perpetuates it, and how to use the available tools and techniques to create a new solution for themselves.

Otherwise, such efforts will be limited to crippled attempts at catch-up to those who have gone before.

Sunday, June 29, 2003

Faff, Force, or Flow? -- A short piece by UK Time Management consultant Mark Forster, attractive first due to its alliterative title, but more importantly for its message about "faffing about," (a great phrase from the Brits -- more acceptable in polite company than our coarser American version "f**king around"), forcing ourselves into action, or flowing smoothly towards our goals.

"But if we are in a true flow state, what is doing the pulling? I would suggest that it is our vision of the future -- one which we have designed for ourselves and which reflects our true wants. Once we have committed ourselves to a vision we truly believe in and want, it will affect every action we take -- almost every thought we think."

This is applicable to both individuals and to organizations, in which clarity of goal and of aligned strategies to achieve more of it provide powerful and positive pull.

Randomity (Coincidence? I Think Not.) -- A (typically) well written and insightful piece from Flemming Funch on "The discovery of meaning in coincidences." Ming's essay reminded me that, in the search for solutions in a system, we all know dealing with individual issues is both ineffective and inefficient, and the better approach is to search for a common root cause related to as many problems as possible. The wider one throws the net -- the more randomly unrelated that problems associated with a system seem -- the better the chances are that a deeper core problem of the system will be identified. That tap-root cause and it's solution can then be translated to solutions for the individual symptoms -- solutions that are aligned with one another and form the basis for an overall, non-conflicting strategy for improvement.

Friday, June 27, 2003

Plan the Process II -- Several days ago, I posted an excerpt of a discussion list comment by Bruce Thomas, suggesting that in a discovery project, while you can't necessarily plan the outcomes, you can plan the promise. In the comments on that piece, Jack Vinson asked...

"By "planning the process" does Bruce Thomas mean that we need to have an explicit expermental plan, replete with expected decision points?"

Not wanting to put words in Bruce's mouth, I posed that question to him, and he responded...

"It's getting to the decision point that often proves to be the challenge.

"You must have an "explicit experimental plan" that forms the concept and scenario for the whole effort, but the scientists and researchers often have that even before a "planner" appears on the scene, because that's interesting to them. But significant project delays can and do occur for lack of a plan and schedule ("you can't schedule R&D") for execution of the more mundane tasks required prior to actual test execution. Examples of these might include processing a procurement to acquire test facilities or equipment; or perhaps design, creation, and testing the software that will conduct the tests (or, ugh! a configuration managed test database).

"In one case, I know of a set of experiments delayed for two years because the research scientist hated the administrative work involved in getting money budgeted, and then getting a statement of work written for a needed contract. All delays were accepted as due to being on the "bleeding edge of technology"."

[For want of a nail...]

"Now, we must also remember that the mere existence of a schedule gets no projects accomplished either, especially remembering that the more theoretical researchers almost always march to their own drummer. For R&D projects, good PM might mean getting a good technical administrator to take care of budgets and procurements and such. As in all projects, it means being aware of the plan and getting people to perform the mundane work that forms the basis for all achievement."

In my opinion, it also means providing a sense of where we expect to be in the "unexpectable" discovery process so that the organization, sponsor, and/or customer can make reasonable assessments about the progress made toward the promised land and whether to stay the course or pull the plug...Bruce's challenge of the "decision point."

"My definition tells you that I care about the people the project was intended to serve, I care about the individual project team members, and I care about the team as a team.

"Who does my definition leave out? It isn't clear to me where sponsors (or investors) fit in. Are they customers? Are they project team members? I want them to be satisfied, too. What about other stakeholders? What about members of the community in which the project takes place?

"I care about those people, too. I feel anxious when I leave out people I care about."

To me, it's pretty clear that sponsors fit into both categories of customer and team. Either they are stand-ins for the customer, or the project is actually being done so that they can serve their customers in a situation where those more easily identified as the builders of the solution are one or two steps removed from real customers. Sponsors are team members by stint of their responsibility to set goals and objectives of the effort, and to justify its existence as an effective use of the larger organization's resources.

Investors are a special class of customer that benefits from successfully serving what is more traditionally viewed as customers. They are not really customers of a specific project, but of the entire organization/project and its goal-seeking (profits in a for-profit situation) abilities.

Most other stakeholders fall into the customer camp, to the extent that side effects of the project effort must not be allowed to negatively impact their interests.

Another way of looking at the various players involved in projects is through the lens of what the Theory of Constraints body of knowledge refers to as necessary conditions, of which three are the absolute minimum to assure success in terms of sustainability or growth in the ability of a system to achieve more "goal stuff." These necessary conditions, introduced in Goldratt's book, It's Not Luck, are usually stated...

Make money now and in the future. (Financial viability serving investors and owners, as well as the long term ability to address the other two conditions -- all three are "necessary" to enable the others.)

Satisfy customers now and in the future. (Not only paying customers, but also those in the surrounding community that are impacted by the enterprise.)

Provide security and satisfaction for employees/associates, now and in the future. (In addition to a firms own employees, this one also implies caring for the relationship with other organizations critical to one's supply chain as well.)

Note the common "now and in the future" thread. As necessary conditions of sustainability or growth, these insist that the system cannot be allowed to pay for current success by squandering the future, and vice versa.

Wednesday, June 25, 2003

"Being the bearer of bad news is no one's favorite responsibility. And it's understandable to want to delay revealing that bad news in hopes that you can quickly recover with no one the wiser. But customers emphasize that they'd rather have bad news now, than worse news later. After all, not having the news till later automatically makes it worse because they have less time to adjust. Customers emphasize that just like the software team, they have work to complete, deadlines to meet and people depending on them. The sooner they know of a delay or a problem, the sooner they can act accordingly to manage its impact on them.

"Although most people have customers-driving-me-crazy stories, the fact is that most customers are reasonable people. They know that things don't always proceed as planned, and they'd much prefer to know the situation as it really is, rather than as we might wish them to think it is.

"When customers seem demanding or unyielding, this behavior may be the consequence of too often being on the receiving end of blatant dishonesty. Dare to tell your customers the truth. They don't like to hear bad news, but they'll appreciate you for giving it to them straight, and as soon as possible. And that's the honest truth."

If my previous posting encourages one to accentuate the negative in assessing situations so you can work on it, Naomi's piece encourages one to tell the truth when real unavoidable negative is found.

Accentuate the Negative -- According to a Psychology Today article -- Our Brain's Negative Bias -- the human "brain is simply built with a greater sensitivity to unpleasant news." It goes on to discuss the necessity for an imbalance of good experience to bad to maintain quality of life. This sensitivity to negativity makes perfect sense, given the primal nature of "fight or flight" responses -- it's only after we successfully avoid pain that we can appreciate pleasure. We need to survive before we can thrive.

(Come to think of it, in project management, we call it "risk" management, not "opportunity" management despite efforts of trainers and consultants to remind us that this process should address both.)

Some time ago, I wrote about something similar to this in one of the earliest columns in my Unconstrained Thinking series. Back then, I pointed out that people are great at being negative. We are always willing to talk about our problems -- we love to "bitch and moan." If someone offers a solution, it's real easy to point out what's wrong with it -- unintended side-effects that the solution creates or why it won't really accomplish its objective. And once we've agreed that something might be a good idea, most of what goes through our minds is why we can't make it happen -- obstacles and hurdles. As I wrote in the old piece...

Have you ever been in a brainstorming session in which the facilitator was one of those “cheerful Charlies” who tell the group that it’s against the rules to say anything negative about an idea? How many rounds of ideas went by before you were biting your lip?

The point is that our problem solving processes should not rely on unnatural positivism, but rather on what people have demonstrated as a common core competency -- the ability to throw wet blankets.

Taking advantage of this natural tendency is one of the cornerstones of the TOC (Theory of Constraints) Thinking Processes. As pointed out in Taking Advantage of Resistance to Change, CRTs (Current Reality Trees) benefit from a wide range of starting point problems so that they can pinpoint common root causes upon which a leveraged solution can be built. NBRs (Negative Branch Reservations) are logical descriptions of what can go wrong if we follow a particular path; once the logic of the reservation or concern is verbalized, something can be done about it. PRTs (PreRequisite Trees) start off with a collection of obstacles; it's obstacles that are the reason we need to develop tasks and milestones to an objective -- obstacles that will be there whether we identify them or not, so it's better to aggressively solicit them then to hope that they're not there. Being a "nattering nabob of negativism" can provide a lot of positive results -- if we have processes to accept it and handle it appropriately.

Those lists of "idea killers" that we're so used to seeing before brainstorming sessions reflect natural negativity. Don't ignore them. Don't try to squelch them. Take advantage of them.

...a review of three "great innovations" from the world of the everyday -- the Weed-Eater, Swiffer Wet-Jets, and Greenies. Also recommended is a longer paper by Pollard -- A Prescription for Business Innovation: Creating Technologies that Solve Basic Human Needs -- that goes into more detail on the above diagram. Great thoughts on figuring out "what to change" and "to what to change to" in a product content context. Armed with such ideas, it's then a matter of creating an effective multi-project delivery machine to set up a rolling ringing of cash registers.

Monday, June 23, 2003

Lessons Learned, Revisited -- A while ago, I waxed poetic about the potential in using weblogs to document lessons learned in project environments. My thought were picked up by McGee and Dina, in the context of their'sandothers' discussion of the topic.

However, I've been giving the subject some more thought recently and have developed another point of view on the general subject of "lessons learned" and "knowledge management."

Lessons learned are nice, but not enough.

Lessons applied are the real source of value of learning.

If a team or individual learns something from an effort, there is absolutely no guarantee that they will remember it the next time a similar situation is encountered. Over time, there is even less of a chance that others (or the organization) will benefit from that "learning." Whether lessons are derived from positive/negative surprises that one would want to recreate/avoid in the future, or from the confirmation/denial of some hypothesis/theory, their cataloging, reviewing, discussing and/or reporting are all actions insufficient to fully take advantage of the "learning."

Lessons learned must be transformed into lessons applied. That application involves putting the lesson into the context of the process with which it is associated. Take the "lesson." Describe it in terms of the causes, effects, and consequences associated with it. Determine (in a timely manner, while still fresh in the mind) what needs to change in the process, what the new process needs to look like, and how to make -- and institutionalize -- the necessary changes so that the desired outcome is assured in future applications of the process.

Along these lines, I have to differ with some recent comments by Esther and Laurent on the lack of value they see as inherent in periodic status meetings. While I might agree that they should be unnecessary at the individual project level, there is no better practice than a weekly half-hour review of a portfolio of projects to highlight both immediate issues that cross project boundaries and to trigger timely actions on learnings and their application. (A half-hour has usually been sufficient for my clients that use buffer management to limit content and focus attention in these meetings.)

If one thinks of such meetings not as reporting to the manager (as Laurent mentions), but to the organization and its future, then a whole new agenda for such sessions can be derived (What's hot today? What can we do about it that leverages organizational support from outside the individual project? What have we learned since last together? What are we going to do about it?) In this way, the concern that Jack has about knowledge retention would become less of an issue.

This approach involves two prerequisites. 1) It requires an understanding of the process, and an easily applied and accessed method of documenting it. 2) It requires "slack" in capacity to be able to address the changes in a timely manner. Regular readers of this weblog probably recognize the TOC Thinking Processes -- especially the Transition Tree -- as useful tools for the understanding problems and processes, and rational multi-project management is a way of freeing up capacity for system and process improvements.

"No one believes the end date of a project." For very risky projects, this end date could be a range of months or even years. For well-understood projects, this uncertainty might only be a range of a few days or weeks.

"Project management tools only map the known future. They know nothing about unknowns and risks, and they give us the illusion that we know what is going to happen."

"Managing by objectives (dates) is dead wrong. Simply elevating the importance of a date won't make it more likely..."

Since I have been working with critical chain project management for the last few years, it is obvious to me that most of these issues can be handled via CCPM. The whole idea behind the philosophy is to build projects with an understanding of the associated risk, and build your portfolio with this uncertainty in mind.

DeMarco's previous books Slack and The Deadline has been one of my favorites for some time now. It looks like there's another heading for my bookshelf.

Friday, June 20, 2003

(Serious) Friday Fun - The Bathroom Effect -- More on my recent theme of communication and collaboration -- from The Salt Lake Tribune. It's an article about Pixar (of Toy Story and Nemo fame) that, in part, discusses the design of the workplace...

""Every guy had an office, and the [wings] were separated so every office could have natural light. But what happened was that everybody became isolated, and no one knew what was going on." So the multiple-building idea was scrapped, in favor of the single unit.

"That wasn't enough for Pixar's CEO, Steve Jobs. "He thought it was really important that there only be one bathroom in the building, for all 700 people who work here," Greenberg says.

"Here's the "bathroom effect" theory, as Greenberg explains it: "If you have bathrooms that are scattered throughout the building, you use the bathroom nearest to where you're sitting. If there was one bathroom, all kinds of people would come together and talk with one another all the time -- you'd meet different people if you were waiting in line. It would enhance communication, and you'd be talking about things outside of work.""

Yep. That would keep the communication flowing. Think of all the real connection that happened in Ally McBeal's fictional uni-loo.

Thursday, June 19, 2003

Plan the Process -- In a recent thread on the NewGrange discussion list, Bruce Thomas offered the following gem...

"This type of project is much like an R&D project -- and many will say that you cannot plan them. I have worked on many and discovered that you can, as long as you remember that you are planning the process rather than the outcomes (by definition, unknown)."

Planning and predicting is about the dynamics; not necessarily the details.

Critical Chain-based Project Management and (not or) XP/Agile Development -- Yesterday, Clarke Ching, a participant on the NewGrange PM discussion list posted a question that Kent Beck posed on a lean development discussion group in which I don't participate. My response via NewGrange seemed worthy of repeat here:

[ching] Kent Beck asked the following question on the lean
[ching] development yahoo group:

[beck] "Here's my question about critical chain--they work
[beck] very hard to time sequence a fixed set of tasks...

Tasks, in the CCPM paradigm, are about creating deliverables with a particular resource (or set of resources working for a solid period of time cheek to jowl with more interaction than one would want to try track in a plan). If one considers an XP/Agile "story" as a deliverable, and the "pair" or "team" as the resource, there is very little conflict between XP/Agile and Critical Chain in terms of definition of task or effort. The details of what the "resource" does during the time that defines the "task" getting to the "deliverable" is not of concern in the CCPM paradigm -- at least as far as "managing the project" is concerned -- only a rolling estimation of time to when that deliverable will be available to the customer or to the next story/deliverable/task/team that requires it.

CCPM doesn't work hard to "time sequence" tasks. We work hard to understand the relationship of potential dependencies of deliverables between tasks in order to assure that missing dependencies don't threaten the ability to keep promises of desired functionality within a given timeframe. If the development of deliverable B requires deliverable A to start working on it, then there is a predecessor-successor relationship between A and B. If there are no handoff dependencies, then it is possible to work on the two in parallel, if sufficient resources/teams/pairs are available to do so. If the two are not both needed to create some larger chunk of value, then they are separate projects.

My understanding is that XP tends to estimate how much work will be done in a short time frame. CC Buffer Management, during execution, uses estimates of how long it will take to do a finite, understood chunk of active work. Future tasks in CCPM, roughed out to appropriate levels of detail (sometimes known, sometimes quite fuzzy) -- to make initial promises to the owner/sponsor/customer/organization are always subject to change based on learnings along the way, with assessments of changes in the consumption or replenishment of buffer allocated to protect the project promise.

[beck] ...using a fixed set of resources...

Promises need to be based on the availability of skills in the time period involved. In the short term, resource/skill pools are fixed for most organizations. If there is an infinite source of skill available (and applicable) in the short run, then a schedule/promise associated with delivering a set of deliverables can take that into account. The promise is then based on the "fixed" expectation of infinite resource. If not, then yes, resources, aka skills, are fixed at some finite capacity.

While I read a lot about XP/Agile work being done based on people "signing up" for stories on index cards tacked to the wall, the recommended CCPM approach to assignment of "people" to tasks is a similar "JIT" approach. As tasks cross a relatively short-term horizon in which their predecessors will allow them to start, available people with the necessary resource skills can be given a heads up that a task that can use their involvement is coming up. In this way, CCPM provides a means of using resources that are not necessarily dedicated (or fixed, per se) to particular projects, and therefore provides the basis for managing not only single projects but pipelines of multiple projects that can utilize a shared pool of resources.

[beck] with tough resource mapping constraints.

If one understands that resources are skills and not necessarily the bodies that contain them, yes, the mapping of needed skills to the work associated with building a deliverable could be considered "tough." They need to be to assure that you have the skills necessary to do the work you anticipate needing to create the deliverable.

[beck] In XP, we work very hard not to have tough resource
[beck] mapping constraints (pairing, tests, collective
[beck] ownership) and not to have a fixed set of tasks (to
[beck] enable business discovery during development).

As mentioned previously, a set of dependent tasks anticipated for the effort is required to make promises about functionality in a longer time frame. The flexible nature of a buffered CC schedule allows for the rational use of rough, uncertain, fuzzy "tasks" where appropriate (often out in the future), that can be revised or refined as discovery or learning takes place in the earlier going, with resulting impacts on project buffers and therefore a quantifiable and manageable impact on the initial promise.

[beck] What does critical chain have left to say?"

The Critical Chain scheduling and monitoring processes are appropriately applied at the "project" level -- in an Agile/XP context at the level of the "release plan" -- which is how it was used by Segway, according to the Cutter Consortium article on the development project of their scooter. It provides a means of making rational promises for efforts that require sets of deliverables that must work together or that depend on one another. It also provides a means to protect that promise as the initial expectations collide with reality -- without having to go into crisis mode at every little blip. Buffers are great absorbers of additional iterations that might be needed to assure optimum quality of delivered value.

I still have a hard time understanding where promise-making (other than in the promises of short-term tasks/deliverables, or in the promise to deliver something larger as soon as possible) comes into play in the Agile/XP approach.

[ching] Could you clarify something for me: Are there
[ching] variables - time, environment, perhaps - where you
[ching] think CCPM and (say) XP might be more appropriate?

If the project is about individual, independent, chunks of value, and therefore about single unconnected stories/tasks/deliverables, then CCPM might be seen as overkill for managing individual effort. Once dependencies between tasks, requiring "release planning" comes into play, CCPM provides an excellent framework for making and keeping project promises, both supporting and utilizing the XP/Agile task/story/deliverable methods in what we in CCPM call "relay-race" and "single-tasking" behaviors.

That said, even in cases in which we are talking about "single task projects," there still remains the necessity to manage the portfolio and pipeline of multiple projects in which the individual efforts exist. The use of CCPM-based multi-project management comes into play as a superior approach to prioritizing the attention of people and skills to the maximum benefit of the larger organization.

Wednesday, June 18, 2003

"How can we apply the Theory Of Constraints to workforce planning and recruiting?"

To the extent that the organization's constraint is associated with some scarce skill, the first question that needs to be asked is upon what skill we want our competitiveness to be based. If that's not where the constraint is, we want to deal with the constraint through cross-training and recruiting (and also unloading work from the people in which that skill resides -- work that doesn't require that skill) to move the constraint to it's desired location. This is what constraint-based strategy is all about, whether we're talking about constraints in people, processes, paradigms, or supply chain partners.

"Where are the bottlenecks to be overcome?"

It depends on the system and it's desired "strategic constraint." That said, it might also be in the heads of people who maintain erroneous assumptions about what constitutes system performance.

All of them, including those associated with TOC. More specifically, one of the most important targets of question is the common assumption that an idle resource/person is a significant waste that has to be "dealt with." Without protective capacity (similar to what Tom DeMarco refers to as "slack"), the system will be too fragile -- too prone to chaotic, hard-to-manage disruptions and difficulties achieving more "goal stuff."

"What new values, behaviors, incentives, measures, and controls will lead to more of what we want?"

Simply, those that eschew local performance optimization in deference to global, system-wide performance -- those that subordinate to carefully developed strategies to deal with the system's constraint.

"How can we get more of the right people on our radar?"

Become known for treating people fairly, honorably, and with common sense. (For example, if your constraint is in your ability to attract market, use the creativity of your people to focus on that -- not on cost-cutting layoffs that will not address the real issue.) The right people will pop up on your radar on their own.

"Spend more time spent in meaningful conversation and less on paperwork?"

Just do it!...once you understand what constitutes "meaningful conversation" and not meaning-less choopchiks...frank and open (and eventually rational) discussion about "what to change, to what to change to, and how to make the change happen."

"Shorten our cycle times while increasing our quality?"

An easy one. Do this to repeal Parkinson's Law and to protect quality from due dates, and this to prevent multi-tasking-driven distraction and rework.

"Along the way, can we take some of the strain out of the process?"

Yup. By eliminating conflicting local performance drivers that force people to do things they know don't make sense.

Death March and Critical Chain -- Having read Edward Yourdon's online draft of the Critical Chain chapter of the next edition of his book, Death March, his opening paragraphs immediately grabbed me.

"An implicit premise of this book, at least for the last several chapters, is that a death-march project represents dysfunctional behavior on the part of the customer, end-user, stakeholders, or entire organization -- which the project manager has to cope with, survive, and hopefully overcome in a successful fashion. After all, what kind of rational, intelligent, ethical, fair-minded person would ask a project manager to accomplish something in half the amount of time that would normally be scheduled, or with half the budget or half the number of software engineers?

"But here's a radical thought: what if the "twice-as-fast" schedule actually represents normal behavior for an IT project, and it's been the dysfunctional behavior of the organization that prevented that kind of accelerated schedule from ever taking place? Instead of desperately looking for strategies to enable a project to take place twice as fast as "normal," what if we decided that our objective was to remove the dysfunctional obstacles that traditionally doomed our projects to take twice as long as they should have?"

In this introduction, Yourdon eloquently lays out the underlying basis of the origins of Critical Chain. It is related to the conflict/dilemma described here...

The assumption -- the "because" associated with the lower horizontal arrow -- that there's not enough safety in typical project plans to deal with project uncertainty, therefore resulting in pressure to extend schedule, cut scope, or overrun budgets, just might not be true. In many cases, as alluded to by Yourdon (and by Goldratt before him), the safety is there, but is too often wasted.

I got a kick out of another passage, as well.

"...the ideas have been so widely praised and endorsed, and have achieved such impressive results, that one wonders why they have not become the "mainstream" of project management. One plausible answer is that many organizations are dysfunctional, and it's very difficult to change deeply-entrenched dysfunctional behavior in the absence of a skilled "therapist," and in the absence of a crisis that threatens the organization's very survival."

I never thought of myself as a "therapist," but in some crazy situations I've been in, that job description might very well have fit.

Over all, this chapter is an excellent high level intro to the basics of Critical Chain for single projects, all the more impressive -- and important -- that it comes from someone both outside the TOC/CCPM community and with substantial project management credentials to boot. I've only got two quibbles worth mentioning. One is a technical confusion of a feeding buffer for a resource buffer in one of the graphic depictions of a Critical Chain schedule. The other is with his mention of software supporting CCPM.

"The actual planning and calculations behind such a scheduling activity can be formidable, and as one might expect, software packages are becoming available to carry out all of the "grunt-work" automatically; examples of such packages are ProChain (from ProChain Solutions Inc., www.prochain.com), and Resonance (from Thru-Put Technologies, www.thru-put.com)."

Whoops...Resonance is not a project management package -- it's a production management package which is now in the MAPICS family. That said, there are other software solutions for Critical Chain, including cc-Pulse (currently -- June, 2003 -- in beta), PS8, and Concerto.

A Clarification on Maps and Plans -- I recently quoted Alford Korzybski, using his often cited statement,

"A map is not the territory."

Upon researching it, I didn't go far enough. The complete statement from is actually...

"A map is not the territory it represents, but if correct, it has a similar structure to the territory, which accounts for its usefulness."

Puts a whole 'nother spin on it, doesn't it?

Project plans and schedules can be made to model a "similar structure" to the project itself, sufficiently reflecting reasonable expectations of the future as well as uncertainty to be useful. (I think someone -- who was it? -- once said that "all models are wrong, but some models are useful." If that's so, then I'm comfortable with the idea that some models are more useful than others.)

Friday, June 13, 2003

A Sneak Preview - Strategy, Resource, Project Management -- Next week, I'm going to be on "semi-vacation," actually getting our Jersey Shore house ready to turn over to renters for the summer.

(By the way, we just had a cancellation, and therefore have an opening for the week of July 5th through the 12th. If you're interested in a week in family-friendly Ocean City, NJ, 2 1/2 blocks from the beach, in a house that sleeps six and is also walking distance to the Boardwalk, let me know via the "Contact" link below. Weekly rental is $1,500.)

As a result, I'm going to be away from my cable modem, which I suspect will crimp my weblogging style for the week. What I plan to work on in my spare time, however, is a multi-part series linking strategic, resource, and project management -- something that should be of interest to those living in a multi-project environment and wondering if effort at the micro level truly reflect the macro direction for the organization. As a sneak preview, here's a "graphic outline" of what I expect you'll see on these pages in a few weeks...

Comments or questions about this graphic will be appreciated and taken into consideration in the eventual text.

Friday Fun -- Effective Use of Email -- For those of you interested in maximizing the benefit derived from the use of email, you might want to check out this conference. (Warning! This link comes very close to, and might even cross over the borders of political correctness. If easily offended, keep moving...nothing to see here. If not, what the heck -- click the link for a laugh.)

"Quality trends du juor are part of American business culture. Quality circles, total quality management (TQM), ISO, QS, Baldrige and now Six Sigma, have all had their day as the quality solution. Employees are tired of this year's solution. When quality programs constantly change, it is difficult to develop a quality system that can show significant results -- and without significant results, management loses support from employees. This is the case with Six Sigma, as with all previous repackaged quality programs."

I've writtenseveraltimes about quality improvement systems like TQM and Six Sigma and the disappointment that often accompanies them. I've also written about how, with appropriate focus -- focus that can be provided by a straightforward awareness and management of constraints. The tools provided by these systems can be used to leverage improvement on a global, bottom-line scale rather than be limited to the usual "local" applications of them. I worry that project selection -- "what to change" -- is not sufficiently approached with due consideration before unleashing such efforts. The primary failure of these systems is their "marketing success" and the resultant roll-out of the approaches across the organizational value chain, where they are wasted on strengthening already strong links of those chains. Any bottom-line impact comes only from those efforts that address the weak links.

Quality-based systems like TQM and Six Sigma, are, by the nature of their source, data-driven, and the statisical tools that they bring to the table are powerful when applied to situations in which answers can be found in the numbers. However, most of the real issues holding back organizations are not found in the numbers that describe the outcome of their processes, but in the erroneous assumptions, paradigms, and metrics that drive undesirable or ineffective behaviors. That requires a different tool-set based in systems thinking, constraint management, and a willingness to really dig into why, why, why, why, why the real problem -- and the real potential for improvement -- in many organizations is not going to be found on the shop floor but in the executive suite. Unless and until top management practices and beliefs are addressed with the vigor that goes into little quality and cost-cutting exercises, the revolving door of "programs du jour" will continue.

Thursday, June 12, 2003

Communication and Collaboration - The Listening Workplace -- Last week, a couple of postings by your humble servant were devoted to issues of communication and collaboration. Today, Hal Macomber (If you've been reading my stuff for the last few months, you remember Hal as one of the three amigos (along with Joe Ely) who wrote a week-long, three-blog magnum opus on Theory of Constraints and day-to-day project work.) has upped the ante and posted up a superb piece that discusses the possible equivalents of Lean's 5S to knowledge/project work. Hal's 5Rs include...

As a major fan of alliteration in the service of mnemonic aid, I'm impressed.

I'm even more impressed with what Hal calls it -- a first draft of a "speculation." It's a definite "keeper," even if only a draft. But he's looking for input and feedback. I encourage you to go and read the full posting and share your thoughts with him. (But please, whatever you do, don't point out that he's actually got 7 R's there instead of 5. You'll break his heart to make him realize his 5R paradigm is not as "lean" -- R-wise -- as it might be.)

"You don't manage change. You help to create the conditions for it. You help people to do what they already want to do."

This is an appropriate stance for one in the "change agent" game, UNLESS the people you're helping are top management, who should be thinking big. With that in mind, I'll agree with the offered prescriptions based on her lessons learned --

1. Think small. "Help happen what wants to happen. Assume resistance is a valid response and don't try to change it. Over a short time, small scale short-term efforts, fueled by the passion of the people leading them, result in large-scale long-range transformation."

2. Focus on the task at hand. "As human beings, when we're gathered together to do something and we don't know what it is, we don't know how to tell if we're doing it or not, and we are going to go crazy. Set your charter to do things that can actually be accomplished with the people you have, with the resources at hand. That doesn't mean you have to dream small. But dreams are the context for your task, not the task itself."

3. Place whatever you're working on in its next largest context. "Look at each part in the context of the whole, that whole in the context of the next larger whole."

4. Be the change you wish to see. "If we want to see more risk-taking, we must ourselves take more risks. If we want people to dream bigger dreams, we must ourselves dream bigger dreams. If we want the whole person to come to work, we must bring all of ourselves to work."

5. Don't just talk -- listen and question. "Not knowing what should happen can be more important than knowing, it can give others the room to create and generate new ideas."

6. Think ahead. "Track what a project allows for and then what that allows for and so on: The bottom line impact of many projects based on people's dreams doesn't show up until the 2nd, 3rd, or 4th derivatives of the projects."

-- with the minor proviso about number 1. To provide strategic direction and alignment for small efforts, the results of number 6 -- thinking ahead -- must include thinking big.

"In psychologist Mihaly Csikszentmihalyi's definition of leadership, the personal is political. The best-selling author of Flow interviewed several dozen exemplary CEOs whose wisdom provides the radical job description of the book's premise: "Leaders must make it possible for employees to work with joy, to their heart's content, while responding to the needs of society." Csikszentmihalyi leverages his definition of "flow" -- the capacity for full engagement in an activity -- to create a blueprint for a workplace in which bringing out the best in workers comes before products and profit. When leaders select and reward employees who find satisfaction at work, they can create an upwardly moral organization.

"In this view, leadership is a privilege that requires checking ego in the coatroom and peering into the mirror to ask tough questions. For example, "How do I determine if something is right or wrong?" Or, "What is my business doing to benefit human well being?" He offers some inspiring stories from leaders who engage employees to go with the flow, including Body Shop CEO Anita Roddick, Patagonia crown prince Yvon Chouinard, and media mogul Ted Turner. Some of Csikszentmihalyi?s advice will sound familiar. Yet he creates a compellingly fresh vision of good business in both a material and spiritual sense. Ultimately, the success of this book lies in its powerful, non-flaky ability to define corporate soul in terms of a company becoming a stakeholder in an entity larger than itself.-- Barbara Mackoff"

It's available at Amazon, where I just one-clicked it. Amazon is also offering a combo deal that includes Csikszentmihalyi's orginal classic, Flow.

Tuesday, June 10, 2003

Update on Death March Redux -- About a month ago, I mentioned an upcoming revision to Edward Yourdon's well known book, Death March. All chapters except one are now available on line. Wouldn't you know that the chapter I really want to see -- the one on the use of "Critical Chain Estimating Techniques" is the one that's missing? Is he going to make me buy the book? If so, so be it. (...reminded about this by s.norrie)

Word of the Day - Procrustean -- From The American Heritage Dictionary of the English Language: Fourth Edition, via Bartleby...

ProcrusteanSYLLABICATION: Pro·crus·te·an
PRONUNCIATION: (audio link)ADJECTIVE: Producing or designed to produce strict conformity by ruthless or arbitrary means.
ETYMOLOGY: After Procrustes, a mythical Greek giant who stretched or shortened captives to make them fit his beds, from Latin Procrustes, from Greek Prokrousts, from prokrouein, hammer out, to stretch out : pro-, forth; see pro + krouein, to beat.

In order to avoid sempiternal, profligate projects, some managers rely on procrustean adherence to milestone schedules and budgets, only to encounter iatrogenic loss of quality.

Monday, June 09, 2003

Sunday, June 08, 2003

Communication and Learning in Projects -- A couple days ago, I ran a list of links on communication and collaboration. Today brings a thread that winds it's way from Phil Windley to Jonathon Peterson to Vattekkat Babu and back to Peterson on the subject of using weblogs in IT and/or Project Management. A few bits along the way got my attention. From Windley...

"One of the chief uses of blogs in an IT organization is narrating your work. How valuable is it for you to narrate your work. How valuable is it for you to read what others are writing?"

Back when I was getting a paycheck from AT&T/Bell Labs, a number of the "members of technical staff" I came across carried around little bound project notebooks -- stamped "Property of AT&T." Some didn't, but those that did maintained both CYA notes as well as real valuable bits and pieces of learning they stumbled on in the course of their projects. I wonder how those paper-based records got used. Lessons learned are hard enough to identify in some organizations. It's even harder to take advantage of them without some easy to use, easy to access knowledge management system. Replace those little bound notebooks with blogs and search engines, and there's at least a chance of doing so. Peterson takes this idea and runs with it, triggering Babu to say...

"A big difference blogging has with traditional PM status reporting is that bloggers want as many people as possible to read what they write, because they are proud of what they are and what they do. Traditional status reporting may be thought of as people with powers ask questions, but no one else. So, for organizations that preach flat structure and not hierarchies, I believe blogs are the way to go. Sure, the information might be unstructured. This is not a difficult problem to solve with proper categorization...The real beauty of blogging for PM is that it evolves. Which means, it supports the simple mind-set of Observe, Analyze, Adjust."

While I'm not sure that status reporting is the real utility for weblogs (project and promise health can be easily understood with simple buffer management techniques -- without the rocket science calcuations and graphs of EV), issues of risk and opportunity identification are another story. Sharing of learnings, surprises and mistakes, is what collaboration for successful project work requires -- not just within a particular team, but across programs and portfolios that might benefit. The first is about exploiting immediate opportunities. The latter is about assuring the future does not have to depend on relearning the same lessons.

The final gem in this thread of weblogs is from Peterson, and it touches directly on the issue of learning -- not about projects but about processes used to deliver them...

"Blogs (and other collaborative workspace tools) are going to come from outside big, traditional IT, where the mechanisms and the layers of middle management that support them are too embedded to change quickly. It is ironic is that at the same time that companies react to the money wasted by neophyte project managers by insisting on PMI certification, the tools and practices needed to deliver the next generation of intra-enterprise applications in a web-services environment are evolving at an exponential rate under the radar of corporate America."

Whether ground level tools like weblogs or higher flying next generation affronts to the "generally accepted practices" endorsed and promoted by the PMI (affronts such as Critical Chain-based PM and/or Agile work methods) have a significant impact on project effectiveness and efficiency is not in question. They are and they will, whether the corporate gate keepers and professional certifiers are aware or not. It would be easier if they didn't feel so threatened, but that is sometimes the nature of change.

If a project is failing, a request to stop the project for formal planning sessions and time-outs will be met with the clearest indicator of a fatal disease: "We can't stop the project for planning, we have a deadline to meet !"

I can't decide whether this is more often related to a head-in-the-sand state of denial, or rather a misguided belief that delivering something is better than delivering nothing, even when that something is out of control.

I do know that it is based, at least in part, by an equally misguided belief that "progress" can be achieved without a plan supporting an objective. (Thanks to C. Keith Ray for the "pointage.")

Wednesday, June 04, 2003

Link-o-Rama - Communication and Collaboration -- Weblog entries from me might be a bit sparse this month, at least compared to April and May, so I figured I'd clean out some of my accumulated stuff, all of which deserve more comment but might merely clutter up my to do list if I don't share them -- at least in a quick and dirty fashion. The general topic that ties them together is communication and collaboration.

What Could Possibly Go Wrong? -- Project risk management is all about clear communication and open collaboration about the realities of an effort or of a situation. There are very few better places to start than with the question "What if?," as suggested in this StickyMinds column (may require free registration) by Esther Derby.

How to Turn a Mistake Into a Positive Event -- If you don't address the "what if's" sufficiently up front, you'll probably find at least a few -- as these Brits put it -- "cock-ups" along the way during your project, or even in less formally managed efforts. Since we typically learn more from mistakes and failure than success, it behooves us to openly discuss the less than ideal aspects of what we do and turn them into lessons for the future.

Shared Vision: A Key to Project Success -- Clarity of purpose, and the extent to which it is shared and owned by the team is a solid foundation for project success, according to Donna Fitzgerald, founder of NewGrange center for project management.

The Information Cycle -- Systems are not only a collection of parts; they are a collection of interactions -- communications for collaborative use of information -- between those parts, according to my friend Tony Rizzo. And I agree with him.

The New Character of Positioning -- The subject is marketing, from a 1997 piece by Doc Searls, one of the authors of the seminal Cluetrain Manifesto. Since every commercial system has, at one time or another, a "constraint in the market," clear communication of where one is coming from with offered products and services is crucial.

Mapping Communication -- A fascinating -- and good looking -- taxonomy of communication flow between individuals and groups.

Getting Up to Speed on Wikis -- If you're reading this, you probably get the idea of weblogs. I know you understand email. You might be familiar with email discussion groups and Usenet. Add "Wikis" to your vocabulary if you're interested in many-to-many communication via the web. This is a good intro to the tool from Jim McGee's weblog.

Monday, June 02, 2003

PSNext from SciForma - Web Based PM Software -- Sciforma has announced PSNext, its new offering for "web-based collaborative project management designed for the global enterprise". I don't see, in their initial info, whether it supports Critical Chain based PM, or constraining-resource based synchronization of multiple projects, as does their desktop and network based PS8 product. But I've got the question in to them. Watch this space for the answer.

[50 minutes later...I got an answer from Mark Stout of SciForma...

Critical Chain won't be in the first release of PSNext. It doesn't mean we've abandoned CCPM by any means. And of course, PS8 continues as a product.

Congratulations! You were the first to notice the new website. It just went live.

Actually I wasn't. I saw a link to the announcement first on Rainer Volz's Virtual Projects weblog.]

Sunday, June 01, 2003

...is not an example of single-tasking. Effective single-tasking is about focus on work for which a successor task in your project needs to proceed (which probably does not include Bob's email reading)...and requires knowing which of the tasks awaiting attention deserves/needs it the most.

Ad: Summertime Dues - Special Offer for Weblog Readers -- Like I've mentioned before, "If there is no billing involved, it is just a hobby." Over the next few months, there is a good chance that I will be visiting family, clients and/or prospects in eastern Tennessee, Los Angeles, Florida, as well as around my local CT/NY/NJ/PA/DE region. I would like to make the most out of the travel involved, and as a result, I have decided to offer -- to the companies of my weblog readers located in these areas -- discounted pricing on various 1- and 2-day workshops. Topics include:

Usually priced for dedicated presentation at $500 (for 1-day) and $800 (2-day) per person with a minimum of 5 attendees, the usual minimums of $2500 and $4000 will be good for up to 12 attendees for the locations mentioned above, including my mid-Atlantic home region. If scheduled for the times I expect to be in those locations, my usual add-on for travel expenses can be waived as well. To take advantage of this offer, or for more information on these offerings and possible scheduling or to discuss the possibility of customization, contact me via web or by phone (908-874-8664).