Tag Archives: project management

Disorganization and Changing Your Mind are Both Expensive

NOISERon DuPlain forwarded me an interesting post from November 2008 (via @duanegran, I believe) called How much do websites cost? It’s a great comprehensive overview of the different kinds of web sites that can be built – the spectrum of customization, interactivity, and intent that dictate whether a web site will cost $200 or $2 million. But what really struck me about this article was one tiny little section that talks about value, emphasizing the relationship between quality, waste, and the changeability of human wants, needs, and desires:

2.) A small company site that has 5 to 10 pages describing the products/services offered by the company. $500 to $2,000 depending on how prepared you are, and also on how clear in your own head you are about what you want. Disorganization and changing your mind are both expensive.

Disorganization is expensive because it blocks action. When your house is disorganized, you waste time and energy trying to find stuff. When the processes you use in the workplace are disorganized, time and physical energy can be wasted engaging in non-value-adding activities, and mental and emotional time and energy wasted in unproductive communications. Wasting time and energy can generate short-term real costs (for example, moving parts or products around a factory or supply chain can delay time-to-market while costing more in fuel for transport), long-term real costs (e.g. reinforcing negative behaviors that lead to breakdowns in interpersonal relationships, teamwork, or morale) or opportunity costs.

Changing your mind is expensive for the same reason: it either blocks new action from taking place, or it eliminates the value that could have been added by prior work. A task is not actionable unless you have the 1) resources to do the job, 2) the information and interest to complete it, 3) the skills and capabilities to make it happen, as well as a clear idea of what needs to be done, and 4) an execution environment that supports getting things done. Changing your mind can erode #2 or #3.

To reduce the risk associated with development, and to control the costs of the project, find out:

  • How much do you really know about what you want?
  • What essential elements are you pretty sure you’ll still want or need in 3 months, 6 months, 1 year, 5 years?
  • What parts do you have the resources, information/interest, capabilities/skills/clarity, and execution environment to get done now? (I call this RICE to make it easier to remember)

The lesson: to get higher quality and lower costs (that is, greater value), focus on those parts of a project that are least likely to change and do those first. This is, of course, if you have the luxury to be agile (highly regulated environments may impose restrictions or limits). Then stop – figure out what your experience working on those parts tells you about how you can approach the problem more systematically and effectively– and repeat the cycle until you iterate to the desired solution. This is the essence of applying organizational learning to your day to day tasks.

Software Hell is a Crowded Place

fireI’ve been thinking a lot about management fads lately, and ran into this 2005 article by Nick Carr, titled “Does Not Compute”. Here’s the part that caught my eye:

“A look at the private sector reveals that software debacles are routine. And the more ambitious the project, the higher the odds of disappointment. It may not be much consolation to taxpayers, but the F.B.I. has a lot of company. Software hell is a very crowded place.”

Carr continues by describing two examples of failed projects: a massive systems integration effort at Ford Motor Company, and a overzealous business intelligence initiative embarked upon by McDonald’s. Both projects were cancelled when the price tags got too big: $200M for Ford, $170M for McDonald’s. The catch is that failure is good, because when we fail we at least know one solution path that’s not workable – we just need to 1) understand that it doesn’t have to be expensive, and 2) have more courage to allow ourselves and our colleagues to fail without getting depressed or thinking our coworkers are idiots. This is often expressed as “fail early, fail often“. (But note that the assumption is that you persist, and as a result of the learning experience, ultimately meet your goals.)

Without an effective team culture, rational managers, healthy relationships with stakeholders, and capable programmers dedicated to continually improving their skills, all roads can lead to software hell. The process of getting there – which is hellish in and of itself – is the famed death march. This is where a software-related project, doomed to fail, sucks up more time, people, resources, and emotional energy at an ever increasing rate until the eventual cataclysm.

Carr also cites The Standish Report, which in 1994, asserted that only 16% of projects were completed on time, and budget, and meeting specifications. By 2003 the percentage had grown to 34% in a new survey. Other projects that were still completed ran, on average, 50 percent over budget. (And this is for the survey respondents who were actually telling the truth. I know a few people who wouldn’t admit that their project was quite so grossly over budget.)

One way to solve this problem is by focusing on sufficiency and continuous learning, starting the blueprint for a system based on these questions:

  • What features represent the bare minimum we need to run this system?
  • What are the really critical success factors?
  • What do we know about our specifications now? What do we not know?
  • What do we know about ourselves now? What do we want to learn more about?

Software development is a learning process. It’s a process of learning about the problem we need to solve, the problem domain, and ourselves – our interests and capabilities. It’s a process of recognizing what parts of building the solution we’re really good at, and what parts we’re not so good at. Let’s start small, and grow bigger as we form stronger relationships with the systems that we are developing. Having a $170M appetite sure didn’t get McDonald’s anywhere, at least in this case.

What is Sociotechnology?

atomicTechnology is the “sum of ways in which social groups construct the material objects of their civilizations.” The things that we use – the “design artifacts” of the processes used to build them – are socially constructed to the same extent that they are technically constructed. The convergence of technological and social insights in the creation, construction and use of artifacts is sociotechnology.

For example, we typically build a bridge when there’s some expectation that people need to get from Point A to Point B, and there’s something they need to bypass along the way (e.g. a river, a canyon, another road). Failure to consider the social factors as well as the technical factors could lead to a “bridge to nowhere” – and we all know at least one person who’s had a problem with those. Non-technical factors pertaining to the environment in which an idea is created and implemented are crucial.

According to Bunge (1998), sociotechnology is the process of applying insights from the social sciences to design policies and programs. More specifically, this is how Gingras & Niosi (1990) explain Bunge’s perspective:


Ten years ago we were talking about the convergence of customer touch points: phone, fax, web, cell phones, email and regular mail. With handhelds and mobile devices becoming more and more ubiquitous, and services like Facebook becoming more integrated into our daily lives, the next convergence is between people and the technologies we use. The boundaries are becoming increasingly blurred, and the impact of this convergence on business must be explored. Reviewing research by pioneers like Tom Erickson is a good place to start. We are all becoming sociotechnical.

(Note: Sociotechnology is an important part of socio-technical design.)

Bunge, M. (1985). Philosophy of science and technology. Vol. 7 of Treatise on basic philosophy, Dordrecht: Holland.
Bunge, M. (1998), Social Science under debate. A Philosophical Approach. Toronto University Press: Toronto.
Gingras, Y. & Niosi, J. (1990). Technology and society: a view from sociology, in Georg Dorn and Paul Weintgartner (eds.) Studies on Mario Bunge’s Treatise, Poznan Studies in the Philosophy of Science, Amsterdam and Atlanta, 421-430. Retrieved from http://www.archipel.uqam.ca/506/01/On_Bunge.PDF
Nieto, C. C., Neotropica, F., & Durbin, P. T. (1995). Sustainable development and philosophies of technology. Society for Philosophy and Technology, Vol. 1, Fall 1995. Retrieved from http://scholar.lib.vt.edu/ejournals/SPT/v1n1n2/nieto.html – (Note: I added this one simply because I really like it, and it’s related to the discussion on sociotechnology.)

Continuous Improvement Begins With Standards

apple-21Software is the executable representation of knowledge. [1] As a result, I find that software development provides a fruitful basis for exploring how problem solving is done by diverse team members in a cooperative (or even combative!) context.

Here is one example. In June 1997, Tom Gilb wrote an article for Crosstalk on “Requirements-Driven Management”. He noted that his purpose was intended to discuss, among other things, “some of the current major problems in systems engineering.” I stumbled upon this article again over the weekend, and it’s still as relevant now as it was a decade ago.

Standards are a prerequisite for systematic continuous improvement; the means to achieve an improvement process, not the ends, according to Glib. Furthermore, he remarks that Deming’s perspective on continuous improvement establishes, in part, that the reason we should adopt standards is to normalize our project to other projects . Once we do that, we’ve opened the doors to be able to use industry best practices, derived from other projects who also applied the standards – so that we can “clearly see the effect of any changes experimentally introduced into a process and not have to worry too much about other potential factors that impact the results.”

Learning, learning, learning. It’s all about continuous improvement through continuous learning, and in presenting this, Gilb is essentially promoting the same philosophy as Alistair Cockburn’s Cooperative Game Manifesto for Software Development. Both see the learning process as the key to successful software development. (So why do we not focus on this aspect of development more?) Glib addresses the issue of learning directly:

“The time has come to recognize that projects are so large, so complex, so unpredictable, and so state-of-the-art new that we have no practical alternative except to maximize our learning process during the project and as early as possible in the project life.

In this article, Gilb also presents “Evo” – short for “Evolutionary Project Management” – which has been used at IBM since 1970. It’s an implementation of Deming’s PDCA (Plan-Do-Check-Act) approach, and the author likens it to Humphrey’s Personal Software Process (PSP).

[1] This definition is credited to Eric Sessoms, who I consider a true artisan of software development. See some of his work at libraryh3lp.com. He likes the elegance of simplicity in his software.

Setting Expectations: Google Voice Search on the iPhone

google1On Friday, November 14th, John Markoff published a story in the New York Times announcing the new Google Voice Search technology for the iPhone. Here’s how he set expectations about the features and release date for this admittedly exciting new tool:

Users of the free application, which Apple is expected to make available as soon as Friday through its iTunes store, can place the phone to their ear and ask virtually any question, like “Where’s the nearest Starbucks?” or “How tall is Mount Everest?” The sound is converted to a digital file and sent to Google’s servers, which try to determine the words spoken and pass them along to the Google search engine.

The search results, which may be displayed in just seconds on a fast wireless network, will at times include local information, taking advantage of iPhone features that let it determine its location.

This provides an excellent example of three points: 1) how NOT to set expectations with your user community, 2) being sensitive to REAL and UNREAL deadlines, and 3) recognizing that sometimes other people (e.g. the media) help set customer expectations for you – especially when your product or technology is popular.

#1: Ever seen that Far Side comic called “What Dogs Hear”? That’s the one where the man is talking to his dog, but all the dog hears is “blah blah blah GINGER blah blah.” When Markoff notes that Google Voice Search would be available “as soon as Friday”, what customers hear is “blah blah blah GOOGLE VOICE SEARCH blah blah blah WILL BE AVAILABLE FRIDAY blah blah”. It doesn’t surprise me that complaints are flying, now that it’s Saturday:

Well, it’s Saturday morning, and as of this writing, the update is nowhere to be found. The bloggers are starting to go meta, writing stories like Harry McCracken’s “How Long Does Google Baby the iPhone?“

#2 Regardless of when Google’s official release date for Google Voice Search is/was, once it was published in the New York Times, the release date was officially Friday, November 14th. And that’s when the REAL deadline was established, because the customer expectations were (purposefully or inadvertently) set!

#3 Google might say “hey, we didn’t actually give the New York Times a release date, they just asked us when the soonest might be that we’d release the product, and we told them what we thought was our best answer.” Lesson: if anyone asks you when’s the soonest your product will be available, they are basically drooling over the new gadgets or functionality you’re getting ready to provide. Think about how many days or weeks you expect the product will still be in development, and then multiply it by three. Or ten. I admire Google, which is why I’m content to use them as an example here – they have a ton of equity with their user base, but their release dates will still be under the microscope and so managing expectations (especially through the media) is even more critical.

Real or Not Real? Deadlines in Project Management

(Image Credit: Doug Buckley of http://hyperactive.to)

Your team is busily working to meet a deadline for an upcoming project, and you’re wondering whether you’re going to be able to pull it together. Everyone is getting nervous, drinking a lot of coffee and Mountain Dew, and staying at the office until the wee hours of the morning. But have you or your project manager stopped to think about whether you are working towards a “real” deadline, or spinning your wheels to meet one that is “not real”?

When real deadlines are not met, there will be negative consequences (e.g. product failures, loss of revenue, loss of goodwill, loss of credibility). Deadlines that are “not real” may have consequences internal to your organization (e.g. loss of goodwill with your boss, delay in providing materials to other employees in your company) but typically can be shifted with less impact.

So why do project managers even set deadlines that are “not real”? Sometimes, internally-focused milestones are required to keep a team aligned, and to provide feedback to assess how well the team is progressing towards externally-focused deadlines. More often, the reasons for originally setting a real deadline have shifted, and the original scenario no longer applies – but no one has stopped to reflect on the fact that the previously set deadline has shifted from being a real one, to one that is not real.

Here are some examples of cases where the deadlines are “real”:

  • “Life or Death”/”Health or Wellness” situation. If you or someone else will die, or otherwise experience a degradation in their health or sanity or well-being as the result of your actions or inactions, then your deadline is real.
  • Time-sensitive systems. This is a special case of the “life or death” situation. If your products or processes will stop working unless you deliver a fix by a certain time, then the deadline is real. Y2K was an example of this kind of deadline (regardless of whether the potential impacts were enough to incapacitate software).
  • Cash flow requirements. If you or your company will run out of money unless you meet your deadline, then you are facing a very real deadline.
  • Previously set external expectations. If you promised a customer that you would deliver their final project on December 5th, the deadline is real. Not meeting the deadline will result in a loss of revenue, credibility, goodwill, and potentially future business as well. Aggressively setting expectations and striving for transparency are two tactics that can help make “real” deadlines like this a little more malleable.
  • Inflexible resource allocations. If you only have access to a team member for a limited time before their visa expires, or if you only have enough money to employ contractors for three months, then getting done what you need to get done in a limited time forms a real deadline.
  • Biological constraints. Oftentimes a woman’s “biological clock” must be considered for deadlines that involve producing new children, but there are other biological constraints that may impact deadlines as well. For example, if today is Saturday and you have a major deliverable due on Wednesday, you could choose to stay awake 24/7 to get it done but you would probably not be successful. Your biological need for sleep (and possibly food as well) would thwart your project plans.
  • Inflexible policy. If your company has a policy that you are required to follow, and it impacts your projects or milestones, it is very likely that you are facing a real deadline (but you might want to ask the “owner” of the policy you are being impacted by, to confirm). As a more extreme example, if a curfew has been imposed in your area, you will need to finish what you’re doing before a certain time of night.
  • Meeting laws and regulations. On April 25, 2002, the Sarbanes-Oxley bill was passed, increasing the stringency of requirements for financial reporting. Companies were required to take steps to comply immediately, and had a limited amount of time to prove their compliance (or else there would be financial and legal consequences). When deadlines are externally imposed, and not meeting them can cause lawsuits and fines, they are real.
  • Shifting sentiment/public opinion/seasonality. If you need to deliver a product that’s meant for use in the summer, and the ice has started to melt and people are headed to the beach, then your deadline is probably very real. If you need to capture “buzz” or other trends in popular culture, and you risk selling less product or increasing your market reach if you don’t finish your work on time, you are facing a real deadline.

How can you tell if a deadline is real? Look for the root cause of the deadline, for example, by asking “5 Whys”. One you know why a milestone or a deadline has been established, you will be better able to find ways to iron out issues that arise when your work is delayed. Furthermore, you will more easily recognize where to focus your team’s effort to prevent negative consequences.

[Note: Some people prefer to call these “hard” and “soft” or “firm” and “not firm” deadlines, but I like the angst that comes along with calling them “real” and “unreal” even though it requires a little bit of hyperbole. Note 2: These elements were brainstormed with Ron DuPlain.]

Recent Entries »