Project Lifestyle

I took Bas De Baar up on his kind offer to do a guest post over at his Project Shrink blog. It took a couple of weeks longer than planned due to some other things going on in my day-job and a spell of fantastic summer weather (one has to prioritize!).

Bas kindly published it today. The post deals with the concept of project rhythm. Follow the link to read it.

Issue lists are the unsung heroes of the Project Lifestyle. This is the last of a series of three posts on how a new look at issue list might radically impact your project outcomes (in a positive way I hasten to add).

In Part 1 I opened the discussion by looking at why issues are such slippery things to manage. I then got perspectives on managing issues from various colleagues who know a thing or two about them.

In Part 2 I applied the Getting Things Done productivity process to derive a workflow for handling issues in a project setting. The key idea here is to introduce a robust, repeatable process to capture and work through project issues. I make the point that

• Issues running around in the wild are the dangerous ones.
• Once you capture them, you can tame and manage them.
• So doing, you exercise a lot more control over the unknowns in your project.

In this post I want to look how some concepts from the social sciences seem to offer proof that a robust issue management process will contribute to improved project outcomes overall, and that this is the secret life of issue lists.

Continue reading "The Secret Life of Issue Lists Part 3: Issues Tip Projects: A Social View" »

Any good project pauses regularly to check whether the scope still matches stakeholder expectations.

So how does this blog project look 7 months in?

Great! If I may say so myself.

However based on some feedback and encouragement from an old teammate of mine (thanks Nilo!) I want to refine and clarify the scope of the Project Lifestyle blog a bit.

In my initial post Scope, Objectives, Approach I stated my focus would be on:

discussing subjects in the field of Project Management, with a particular focus on implementing packaged software: Oracle Applications, in the broadest sense

In practice I have found myself frequently exploring two themes

• The human factors element of project management. To borrow from Bas over at Project Shrink: projects are about people: deal with it!
• Oracle Applications themes with a special focus on ERP, and Oracle E-Business Suite in particular. Global single instances and multinational implementations themes make a regular appearance as this is where I have spent a large amount of my professional life

The Software Industry resembles the Fashion Industry in some ways: it’s all about This Years Model.

So while most Oracle-facing pundits (internal and external) continue to focus on features & functions of the Next Release I will continue to report and comment on the hard and tricky work of getting it all up and running and delivering business value.

The project work style has moved from being infrequent or incidental to a continuous stream of parallel and overlapping projects for our customers, many of whom are poorly prepared and equipped for this reality. This led me to look at the phenomenon of projects as a lifestyle choice. Hence the name of the blog.

Continuing a series of posts on Global Single Instances architecture strategies. This one’s a touchy subject: maintenance.

Maintaining a Global Single Instance presents a number of unique challenges to the IT organization, all of which can be overcome with some common sense, discipline and by taking advantage of all of the relevant features that the software and hardware infrastructure offer you.

Where for art thou Downtime?
The most obvious challenge for GSI maintenance is finding downtime to execute the maintenance. What influences the (potentially) available downtime? Key influences on downtime are listed below in no particular order.
Instance Status
Typically it costs more to have a production instance offline than a project instance.
However, one usually has more project instances to maintain as there is usually a many-to-one relation of project to production instances. Furthermore, project instances often need to be maintained more frequently to support project progress or to promote patches through the test instance set to production.
In some cases project instance downtime can be very costly. The cost of project team delays (including expensive consultant time) can add up quickly and is frequently overlooked.
Equal care can be required in planning project and production instance downtime depending on the project phase.
Instance Functional Footprint
The downtime cost for an instance depends to a degree on the business processes supported by the instance.
Revenue side or customer-critical operations (e.g. billing, manufacturing, shipping or some CRM functions) carry a higher downtime cost to the company.
These business processes can frequently have a 2- or 3-shift or 24x7 character.
Timezones
The more "global" an instance is (the number of timezones to be supported) the more difficult it can be to find a maintenance window that does not impact production (or project) operations somewhere. This can be made even more difficult when you add a new region to the program (e.g. adding project operations in Asia-Pacific to instance with Americas & EMEA) or dealing with regions with a shifted workweek (e.g. Sunday - Thursday)
System Overheads
Some system aspects do not impact the available downtime as such, they impact the scope of what has to be executed in each maintenance window. Examples of this are multiple languages installed (linear impact on number of patches to be installed) and synchronization feeds to reporting instances/DWH (requiring stop/start/resynchronize time in the window).

GSI Maintenance Management
Each of the influences on downtime can be be mitigated.
Communication First
First and foremost all maintenance schedules need to be clearly communicated, highly visible to all relevant parties and frequently updated with the planned activities to be executed in each window. Communication needs to be a combination of static information on the project/IT website on the standard maintenance windows and similar relevant information and dynamic updates via email blasts, news/rss updates on the planned activities for each window and maintenance start/stop notifications. All of this builds an operational environment where maintenance is an expected element of the landscape and there are no surprises when an instance goes offline for patching or other maintenance.
Planning
Allied with communication, plan the instance maintenance windows 6 - 12 months in advance (for *all* instances) and publish the plan. This becomes a framework for negotiation (particularly with the project instances) but at least everyone is starting with the same baseline of information.
Slots and Kaizen
Use a kaizen process of refinement to keep maintenance under control and drive performance.
Plan 2x - 3x per week windows for 4 - 6 hours (say) for project environments. Publish as SLA. Then drive to improve to get to 1x or 2x per week.
Plan 1x per week 4 - 8 hours window for production environment(s).  Publish as SLA.
Then keep driving process improvements to get to 2x per month, then 1x per month then 2x per quarter...

Remember it is not about the starting point, it is about the journey of continuously reducing the frequency of planned downtimes and improving reliability and predictability of the process.

Which Slot? Timezones
As stated in the section on influences - timezone coverage can squeeze your maintenance window slots badly. But you can also take advantage of this. Maintenance windows from 0200 - 0600 CET can also be expensive in terms of overtime if your data center staff are also in the CET timezone.
Using (for example) staff based in  IST (India) combined with PST (California) or EST (East Coast US) can mitigate this very well and give 24x7 coverage. Make the timezones work for you.
Use Available Technology
Invest time in understanding how to get the best out of the technology you have and what additional technology you may need to acquire to meet your downtime requirements. I will always recommend colleague  Steven Chan’s excellent blog for more detail on this subject – but here is a grab bag of suggestions to follow…

• Invest in the hardware infrastructure (e.g. disk technology) to speed backup and recovery operations
• Hot backups must be routine
• Use the well documented features of Oracle E-Business Suite to minimize patching time. Some examples:
• Minimize the number of individual patches and human interference in patching by merging patches
• Minimize the software distributions to be patched by consolidating to a single shared software directory
• Run the patches faster by spreading multiple parallel patch utility worker processes over multiple servers
• Install patches in offline staging area (staged APPL_TOP technique)
• Analyze which patch (components) can be installed hot according to Oracle Development guidelines

As a bit of an experiment I have set up the Project Lifestyle Twitter account at http://twitter.com/PMLifestyle The idea here is really to use it as a companion (micro)blog to this one. Let’s see how it goes…

[Update 22-Apr-2009 Links to the mind map file, free Mind Manager Viewer and same in pdf format added. Apparently IE can’t render the embedded viewer either. Kudos to Hans Henrik Krohn for pointing this out.]

This is the second part of a discussion on the secret life of issue lists in our project lifestyles.

In Part 1 I opened the discussion by looking at why issues are such slippery things to manage. I then got perspectives on managing issues from various colleagues who know a thing or two about them.

In this post I’ll see how some of the latest thinking in personal productivity intersects with issue management in projects.

Issue Management and GTD

I compared my colleagues’ perspectives on issue lists and issue management to some of the concepts outlined in the action management method "Getting Things Done” (GTD) developed by David Allen.

Basically this method rests on the principle that a person needs to move tasks out of their mind by recording them somewhere.

That way, the mind is freed from the job of remembering everything that needs to be done, and can concentrate on actually performing those tasks.  Hmmm…sounds like the projects lifestyle to me…

Two things distinguish GTD from other time- or action-management systems.

GTD is not about prioritizing up front.  It is about dealing with things as the come using a standard workflow.

Secondly GTD the idea of grouping tasks by the context (defined as a place or set of available resources) in which they are to be performed.

Really I wanted to see what would happen by applying GTD workflow to the project context and the issue process in particular. 

Here is a MindMap I built to document the steps in the workflow. You can grab this file directly from the link and view using the free MindManager Viewer.

You will need to view this in IE or install the excellent IE Tab plugin for Firefox to view this embedded MindMap Viewer.

For the truly afflicted you can grab the mind map as a pdf file.

Built by Mindjet LLC

The biggest thing really is the concept of collecting issues out of the minds of project team members and users and getting them recorded.

Issues running around in the wild are the dangerous ones.

Once you capture them, you can tame and manage them.

So doing, you exercise a lot more control over the unknowns in your project.

In the next and final post I will examine how better management of issues may have an overall impact on project outcomes by referring to Tipping Point theory.

Sometimes little things can make a big difference, and sometimes those little things are right there in front of you, waiting for you to notice them.

Take project issue lists for example

As a key project document I first started getting interested in them about 10 years go when I was doing a lot of Critical Accounts & remediation work. It was impossible to go into a project and have an agreed issue list waiting there, ready for you to work on.

Nothing has changed. Getting agreement on what the key issues are and their status still feels like getting blood out of a stone.

Recently I decided to have another look at issue lists in projects in the light of some of the latest thinking in the fields of personal productivity and sociology. I wanted to see if that led to any new insights on how those concepts could be applied in the context of project teams.

Obviously the underlying question is "If we manage issues better, will that improve our project outcomes?”

I was pleasantly surprised with the results. 

Continue reading "The Secret Life of Issue Lists (Part1)" »

In one of my latest MIT newsletters (free subscription of course!) a great piece on testing assumptions.The Importance of Testing Assumptions

Behavioral economist Dan Ariely's talk from the TED conference last month was recently posted online. In his talk, Ariely (who wrote the best-selling Predictably Irrational) addresses, through his own experience, a topic that is also quite relevant for innovators in an uncertain environment: the importance of testing assumptions through experiments.

He also makes some great comments on cheating (of all things).

• Everyone cheats, a little. But only to a point where it does not challenge their self image of being a “good” person
• People start cheating (more) when a member of their in-group blatantly cheats
• People stop cheating when a member of an out-group blatantly cheats 
• People cheat less when confronted with moral standards (people lie less about remembering the 10 commandments, for example)

In our project lifestyles we come across this phenomenon all the time. No so much cheating as social behaviors like groupthink that we as project managers need to find ways of combating.

A good start is to be aware from the outset that people are sometimes “predictably irrational” and may not be sensitive to your rational, evidence-based arguments…

I am going to wrap up this initial series of posts on Global Single Instances with some thoughts on the number of test environments you’ll need to support your project(s). It may not give you instant happiness, but it will give you:

Many project or program managers have no firm idea on this subject and delegate the decision making to the technical lead/solution architect/chief propeller head.

This is OK if you accept that having no firm idea = having no clue. Alternatively (waxing lyrical here):

If you don’t stand for something you’ll fall for anything.

So what do I recommend PM’s need to know? It depends on the size of the rollout and the solution footprint.

Continue reading "GSI Architecture Strategy Part 4: Project Environments & Wrap" »

Crew (or Cockpit) Resource Management (follow the link for the Wikipedia article)  is a safety concept that originated in the aviation industry. Research had found that the primary cause of the majority of aviation accidents was human error, and that the main problems were failures of interpersonal communication, leadership, and decision making in the cockpit.  CRM is a mandatory training program that addresses exactly these issues of interpersonal communication, leadership and decision making. CRM encourages a culture of open communication, where it is OK to question authority in the interests of flight safety. It is aimed to increase the ability of the crew to effectively manage flight within the context of wider aviation system through better situational awareness. Even if you are a single pilot aircraft you have to deal with the wider system of Air Traffic Control or other ground services, other aircraft, terrain, weather etc…

As a project or program manager, what aspects of Crew Resource Management might help you avoid crashing your project in bad weather?

An article on the BBC News website gave me an insight in how CRM applied to a specific kind of project environment (surgical operating theatres) could reduce patient deaths by 40% and post-operative complications by more than 30%. All they did was introduce a single A4 page checklist that needs only a few minutes to complete. It focuses on basic good practice before anesthesia is administered, before a patient is cut open, and before a patient is removed from the operating theatre. So simple but so effective in improving outcomes for the primary stakeholders (the patient).

http://news.bbc.co.uk/1/hi/health/7829910.stm

So what kinds of simple changes could we make in Project Management adopt and adapt?

In another vein I thought I would create a small movie on the subject. Interesting what 90 minutes spent with MS Powerpoint, CoolIris (they have a nifty ppt plugin)  and Picasa build for you.

A different kind of improvised explosive device.