When not to release a project

Best-practice project management advocates nominating dates for the release of your product or service and, as we all know, having firm committed dates are good; right?

Wrong; because not all dates are created equal. Here’s some examples: Public holidays and religious holidays. Let’s imagine a scenario. We’re going to deliver our next software release for Christmas. That’s a committed date and it’s problematic. What happens if we slip? Do we work extra hours? Are we working through Christmas?

In general people take vacations around Christmas and productivity drops. So why arrange a delivery at a time when we know everyone isn’t fully engaged? Christmas is just a well-known example, the same logic can be applied to other religious festivals and Public Holidays.

We’re aren’t done yet. Every weekday present us with a challenge; Mondays and Fridays. Setting delivery dates at the beginning and end of a week isn’t smart because on Mondays people are re-engaging with their work and disengaging on Fridays. So that leaves us with Tuesdays, Wednesdays and Thursdays. Fortunately most Public Holidays are on Mondays or Fridays so we feel less impact.

This discussion has been framed in terms of our delivery to a customer but the reasoning applies to our Customer too; they may not be willing or able to take delivery on Holidays or the beginning or end of the week.

So here’s your challenge. Look at your delivery dates and days and then ask yourself “will people be fully engaged around the delivery date?”. If the answer is no make a change.

Great Expectations Part 1

Imagine a hungry customer going to a restaurant. The customer sits down and asks the waiter for the menu. The waiter says it’s late, the kitchen is closing and food can be made available but the customer must make a selection from the menu to get the order into the kitchen. The waiter is keen to see the customer served and waits at the table to take the Customer’s order. The customer looks through the menu noting the options available.

After a few minutes the waiter asks if the Customer is ready to order and the Customer says not yet. To the Waiter’s exasperation the Customer becomes distracted and starts talking on a cell-phone; the Waiter overhears the Customer saying she’s hungry. Other Customers arrive; they are hungry and they want to be seated and eat. The Customer turns to the Waiter and complains they are hungry and asks why are they not getting food.

This scenario is familiar to many small business owners. Your client engages you for a job and states the work must be completed quickly. Part way through the work you need your client’s input and your client goes silent. As your client’s delivery deadline nears you repeatedly ask for client-feedback and your client remains silent. The day before delivery your client complains work isn’t being completed and the deadline will be missed.

This is an instance of what I call ‘asymmetric engagement’. The client believes their involvement was initiating their project and engaging you. The client’s involvement is an event; a single activity in time. To you, your involvement is a process; a sequence of activities over time.

So what’s the solution? We need to be clear about what we’re offering clients; are we offering a transaction or a process? In our restaurant example the Customer believes they are being offered a transaction; food for money. From the restaurant’s perspective the Customer is engaged in a process with the Waiter. What’s key is stating what the Customer is committing to and reminding them of their progress. Examples range from the obvious to the not-so obvious, here’s two examples.

You buy a book from a store. The terminating event is you receiving a receipt for your purchase. Before that there may have been some book-browsing. One aspect of book-store’s continued survival is they accommodate several processes for selecting books and terminate with the same transactional event.

You engage a software developer to build you a web-site. The web-site requires the developer to obtain your input on look-and-feel options. After a couple of iterations of feedback you may believe you are done, your web-site is complete and you move onto other tasks. From the developer’s perspective you are not finished and are still in the development process. In this example your progress through the development process is not apparent.

How can we improve our Customer’s experience?

Here’s the key questions to ask yourself:
1) Am I exposing the Customer to a transaction or a process?
2) Is my Customer exposing me to a transaction or a process?
3) Introduce expectations for end result and process.

In Part 2 I’ll address question 3 and how we can structure expectations.

Cultivating your project

Running a successful project is like cultivating a garden. We plant seeds and we nurture them to bloom. Below are project seeds-for-success, which, if nurtured, will create a thriving project.

1. Establish a Vision

A project that lacks a coherent vision is bound to fail. The vision must be broad enough to inspire, yet specific enough to target. JFK’s vision that “this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth.” is the perfect example of a vision statement. It defines the goal concisely, and allows each person to envision their part in the process, while providing a meaningful timeframe.

2. Align your people

Once your goal is recognized, the resources at hand must be directed appropriately. Each participant must understand his part in the process.
Conflicts and duplications of effort can be avoided; if not, they should be resolved rapidly. Different tasks have differing timeframes; when resources become free, they must be redeployed in a timely manner.

3. Identify and track your risks

In any project, there are risks; from project budget shortfalls to platform changes to personnel and resource shortfalls. Not only must risks be
assessed, they must be addressed – ranked by loss potential and probability of occurrence. Establish a top-10 project risks list and review it regularly.

4. Understand your project’s scope

Defining the scope of any project is crucial. “Scope Creep” (sometimes called “Kitchen Sink Syndrome”) refers to uncontrolled changes to an
approved project; generally feature additions, and usually without proper budgeting of time and resources. Every Project Manager knows that
’scope creep’ is the death of many projects, yet somehow it remains one of the major risks for any project. Not only does it throw off schedules
and budgeting, it will often shift the focus of the development team, leading to a loss of the initial vision (#1), and misalignment of
resources (#2).

5. Measure progress

Milestones are a must. They enable the progress of a project to be measured and controlled. The inability to make track progress is the
inability to make progress. Milestones set deadlines within a project. They may mark occasions where a transition occurs or where key questions may be answered (or decisions required) that could alter the course of a project

6. Adapt your plans

“No plan survives contact with reality” is a truism that every project manager must take to heart. As good as an initial strategy might be, no
strategy can take all contingencies into account. Analysis must take place in order to note areas of concern and to plan how to deal with likely
problems in the near future. This is tactical planning, not strategic. Tactics are ‘in process’, or in military terms, ‘battlefield’ choices which
must be made. The initial strategy is not being discarded here, the object is re-alignment with the initial strategy as best as possible on the fly.

7. Adapt your people

In almost any project, there will always be an area where skills are lacking within a project team. A successful leader not only develops the finished project, but also the people involved in the project. Improving technical skills, increasing effectiveness, and boosting morale and retention leads to the success of not only the project, but the company as a whole in the long run.

Take a look at your project using the points above; which ’seeds of success’ can you nurture?

Why do some methodologies fail – re-framing the question

After a past experience with Scrum I wanted to write about the conditions under which Scrum projects can fail. A Google search located a presentation from Joseph Pelrine and Jiri Lundak describing a workshop they ran to reveal why Scrum projects fail (http://tinyurl.com/9j2az6). Pelrine and Lundak’s workshop starts by considering the conditions for project failure. This seems like an important first-step but I realized the question may be misleading.

I’m going to use a different approach by asking the question; under what conditions is Scrum applicable? Why ask the question? I was watching Ken Schwaber’s Google Tech Talk video titled ‘Scrum et al’ (http://tinyurl.com/j58cr). 29 minutes into the video Ken states 30-35% of Scrum implementations succeed. What happened to the other 65-70% of Scrum implementations?

After further consideration the question can be broadened to other tools/techniques/methodologies for running software projects, for example; under what conditions are Gantt charts applicable? or, when is waterfall development applicable?

Changing the question helps me address other persistent questions like; why do we still use Gantt charts? Why is waterfall development still used?

Take a look at your own project; what tools, techniques and methodologies are you using? Now comes the hard question; why do you use them?