LBi

To Assume or Not To Assume

Posted by Jeff L July 27th, 2010

A commonly known adage about assumptions is that “to assume is to make an ass out of ‘u’ and me.” This reinforces the viewpoint that assuming something is bad while the resulting corollary is then that knowing something is good. That seems simple enough, but things in the real world are rarely simple.

For instance, what does one mean by knowing? Webster says “to know” means “to be cognizant or aware of a fact or a specific piece of information” but maybe “knowing” in the English sense is too broad of a term – the French have two different words for the verb “to know” – savoir and connaître. Savoir is when you know facts and can also be used to say you know how to do something. Connaitre is when you know a person or a place.

This etymological discussion may be very interesting to linguists but how does it affect the business world? In business, knowing something is an incredibly valuable asset. There is another commonly known adage about how “knowledge is power” and power in the business sense means the following: revenue, market share, return on investment and profit. Often though, what one needs to know is not available at the time one needs to know it.

Stormtrooper doing “Hamlet” courtesy of Stefan
 

For instance, you may be embarking on a product launch and not everything that needs to be known is known. From a high-level, you may not know if your competitors have products in development that directly compete with yours. From a very detailed level, you may not know if your product’s website will need videos to demonstrate how your product works or if an image slide show will just as easily do the trick. These are just two examples but if one were to draw up a list of the known unknowns for this hypothetical product launch, I’m sure one could list tens if not hundreds of items. Knowing everything will either never happen or it will just take way too much time. So, what should you do?

The way to avoid this potentially endless spin cycle of indecision and inaction is to break out that bad little verb that I mentioned at the start of this post. You need to make assumptions and “assumptions” in this instance are a good thing, actually a very good thing. For our hypothetical project, we would assume from a high-level that our competitors do not have a competing product that will launch when ours does and that even if they did have one in development, we would assume that ours would be in-market for a full three months before theirs launches. We also assume from a very detailed level that videos would be needed, that these videos would be no longer than two minutes in length, that they would be shot in high definition and that they would be used not only on the website but on kiosks and social media channels. With assumptions, you can develop a plan for what tasks and deliverables are needed, what resources are needed to complete the tasks, how much time these resources need to complete the tasks and how much money it will cost in order to complete the project. Without assumptions, you just remain stuck in a rut.

The key to breaking this rut is admitting what you don’t know, early on, as a basis for determining your assumptions—and then eliminating the ones that have the least effect on the accuracy and outcome of your plan. There is a balancing point, that needs to be watched, which can be easily overrun, where too many assumptions will potentially drive inaccuracy or force too much rigidity into the plan, because the assumptions create a false reality—a set of conditions that are highly improbable to occur as assumed (this is where the old adage can come back to bite you on the you –know-where—e.g. believing that lighting will strike when and where you want it to, so that your Flux Capacitor will get its 1.21 Gigawatts). The key, then, to developing good assumptions is to make sure the team/client places a value and prioritization to each assumption, so that the project planner knows when one requirement of the plan takes precedence over another, and to ensure that the planning decisions are focused on the critical path for your project, and not a compulsion to pin down unknown minutiae.

So, the net / net is that adages are not always true. While you may be an ass if you assume that someone is going to turn off the faucet that you left on (and are surprised about the resulting flood in the kitchen), you also may be an ass if you do not make assumptions in order to get a project going. Assumptions in the project sense are not examples of laziness, they are merely placeholders that exist until better and more definite knowledge comes along. The tricky part moving forward, once you’ve developed your assumption-supported plan, is to make sure your team and the client understands the budget and timing impact of changing each specific assumption—a great initial purpose for developing a related risks & issues log. The main effect of not managing your assumptions in near-real-time once the project begins will often lead to unperceived scope creep and difficult conversations around change orders later on in the project cycle, when no one is expecting it. Fun-fun.

Tags: adages, Delivery, projectmanagement

0 comments Share

Stand and Deliver

Posted by Jeff L May 4th, 2010

The title of a classic 80’s movie – about an inner city teacher that coaxes his rough around the edges students through unconventional means into some of the country’s top mathematics students – is my clever way to introduce the world of project management, which at LBi is fittingly enough titled “Delivery Management,” to this blog. Project Managers, or Producers as many who manage creative projects often are called, are in many ways like teachers who, like Jaime Escalante, push you out of your comfort zone in order to get you to produce your best work.

Years ago, project management roles mostly existed in the engineering or construction fields but then a shift occurred in the way that most of the world essentially viewed work. As a discipline, project management has become entrenched in the way businesses operate in the 21st century and nowadays, most work activities are considered “projects,” whether they involve planting a vegetable garden or launching a product or service. There is even an organization to bestow honors on you – fittingly enough titled the Project Management Institute (PMI).  While seeing the acronym PMP on a resume (it means “Project Management Professional,” designation that can be earned through PMI coursework and testing) is not as routine as seeing MBA or CPA, it is certainly becoming more and more common.

How do they do it?  The head of our department Nick K. said to me once that to be successful at delivery, one needs to “make sure that in order to get from point A to point B, the team does not run through every other letter in the process.” Simply teaching a subject Project Managers are not – rather, they are leading an entire team towards a stated goal, whether it’s for the entire class to succeed at a standardized test (a la the movie) or for a web site to launch on time and budget.

In order to move a project from inception, when it’s just a pie in the sky idea, to completion, when it’s an actual thing (form withstanding), one generally takes a series of well defined steps.  In order to take these steps as efficiently as possible, systems of processes have been developed and codified which fall into basically two types: the traditional and the innovative.

The easiest and most well known method of bringing a project from start to finish is the traditional linear waterfall approach. This approach is the one with which people are the most comfortable because there are clearly defined sequences of events, each with its own corresponding deliverables, and all these events need to all be sequentially accomplished and approved in order to successfully complete a project. As you can imagine, this is a slow and methodical approach – think tortoise in the “Tortoise and the Hare” fable where “slow and steady wins the race.” It may be exacting, but it will be right.

Over the past decade or two however, the explosion of digitally focused industries and their corresponding development activities, such as application development, web development and gaming development to name three, have led to the creation of other newer approaches. These approaches have not only grudgingly gained acceptance but are steadily winning converts. Two in particular are Agile Management and Scrum Management. It is not shocking to hear that these iterative, incremental frameworks attempt to speed projects to completion and thus products and services to market as quickly as possible. Think hare – though in this fable it beats the tortoise because the one who gains the most market share the quickest wins.

After reading about these two general approaches, the traditional and the innovative, you may be wondering “What does LBi think about all of these processes?  Which does it feel is right? Which is the way the story should end?”  Our answer to these questions is “neither or both” – it all depends on the business goals and the corresponding projects that are conducted to meet them.

The term “process agnostic” has been thrown around internally for the way we approach projects and I believe it is an apt one. In the end, processes are just tools that are used by people to manage other people in order to produce (hopefully) great work.  At LBi, I’m happy to report that we choose the right tool for the right job.  We’ve learned that though you might want to try, you cannot hammer a screw.

Tags: agile, Delivery, pm, producers, production, projectmanagement, scrum, waterfall

0 comments Share