I thought I would kick off this blog with a confession.  I often stay to watch the credits at the end of a film.  Sometimes it’s to see the outtakes (often quite amusing…), other times to see the effort that went into the production. Some of those job titles are very creative (e.g., regarding the role titled ‘Best Boy,’ well, what about Best Girl??).  After recently watching the credits role in Avatar, I was curious about steps they took to manage project dependencies, in particular given the multitude of production teams.

Thinking about your current project, consider the project dependencies that might cause delays in meeting key milestones.  You probably have seen some of these dependencies in your travels.  Some are predictable, some take up the time of your limited resources, some lead to scope creep on your project, and others surface during your project out of the blue.

Returning to the Avatar film for a moment, there’s an interesting scene when the main character faces a ‘right of passage’ task.  Let’s refer to this mission as his project (and no, I will not give anything away).  His task?  To ‘bond’ with a flying bird.  His ‘sponsor’ informs him just before boarding the bird that he will know he has found the right bird to fly, as this is the one that will first try to kill him.  His facial expression says it all.  Who could have anticipated this?  And not to mention this all took place a top a mountain floating in mid-air?  One wrong move, and ……you get the idea.  I suspect your project dependencies may be more predictable.  Maybe.

When was the last time you evaluated your project’s dependencies and assessed their risk to your project?  Consider the following questions -

·         How will delays on other projects/initiatives impact your project plan and workload of your resources?

·         Has your project board weighed in on the impact of these dependencies?

·         Have you introduced sufficient contingency within the project plan?

·         Have you considered new dependencies that have surfaced since your project launch, and factored them into the project plan?

Project methodologies introduce tools to track issues and risks, but how frequently do you monitor project dependencies and assess their impact?  These risks may not be as choppy as those found when boarding a flying bird for a ride to prove your worth (maybe…), but consider best practices to minimize the turbulence.   Define concrete steps to bring them to conclusion, move them forward at each opportunity and monitor throughout the project.

“Tact:  A keen sense of what to say or do to avoid giving offense; skill in dealing with difficult or delicate situations.”[1]

Clients hire consultants to help them with a problem.  In the Oracle contracting world, the client may need a new system or modification to their existing system and they do not have the technical expertise to perform the needed work.  They hire a team of consultants to assist them with their project.

As the project progresses, we may see problems or issues that need to be addressed.  We might also be asked directly by the client to comment on an issue that is in our particular domain.  In either case, the client expects us to provide them with a competent recommendation for a solution.  There are occasions when, much to our surprise, when the client resists our recommendations.  This can be a frustrating experience that has the potential to increase tension in our relationship.

How should you handle the situation when you have a professional disagreement with your client?  First and most importantly – don’t take it personally.  It is hard to do, but you need to separate any emotional attachment to your ideas.  Once you’ve done that (as best you can), then the next step is to try and understand the client’s position.  Generally, resistance to ideas comes because the client is feeling either loss of control or vulnerability.  This can be difficult to understand and is probably something that most clients won’t express directly.  You’ll rarely hear a client say “Your solution makes me feel vulnerable.”  However, your mere presence can make the client feel vulnerable – they are at your mercy to do the job right.

The focus of your conversations when discussing a recommendation or solution should be on the objectives and outcomes.  If you can get agreement on what it is that you are trying to achieve first, then it will be easier to get agreement on how to achieve it.  Plus, by focusing on the outcomes, you can assess if the client doesn’t agree that your recommendation will meet those outcomes.

Next, work together with the client to produce a solution.  Ask them specifically what they don’t like about your recommendation and how they might change it.  Get them to elaborate in some detail and then incorporate what makes sense into the final solution.  This brings them on board and helps them take some degree of ownership, which can minimize that sense of loss of control or vulnerability.

Finally, accept that some solutions may have to be less than ideal for non-technical reasons.  There may be political/organizational reasons why one way of achieving an outcome is more acceptable than others.   For example, it could be for simple reasons such as the CFO doesn’t like reports formatted a particular way.

If you are able to not take resistance personally, understand the client’s position, and let them be part of the solution, you can tactfully handle disagreements and achieve better outcomes with your clients.

When economic times get tough, many folks look to one area of the economy that doesn’t always follow commercial trends.  That area is the government.  As we’ve seen with this latest recession, government spending can increase (especially at the national level) during tough times.  If you’ve been thinking about getting involved with a national level government project, you should be aware of some of the differences in the working environment.  Here are some important factors to consider:

1.       Volume/size.  Few commercial enterprises reach the scale of the typical government project.  As an example, the US Department of Veterans Affairs is undertaking a project to replace their financial/accounting system.  With about 280,000 employees, an annual budget of around $93 billion, and 153 medical centers (among many other elements), the VA does a lot of business.

2.       Oversight.  Scrutiny and compliance, especially for a visible government program, require a higher level of effort.  There are mandated reporting requirements for the typical government project that simply don’t exist in the commercial world.  Plus there are many organizational layers that have an interest in the project.  In the US Federal government, this could include not only Department level management review (if the customer is an agency within a department), but also the Office of the Inspector General, the Office of Management and Budget, as well as the Government Accountability Office.

3.       Politics.  Office politics often has an impact on the conduct of a project.  The level of politics on a government project can reach very high levels.  Efficiencies and other business process changes may be resisted despite their operational benefits.  Pressure from the public can also dramatically impact how business is performed.

4.       Skepticism.  Many government workers have seen multiple grand initiatives to transform operations fail.  Some of these have been high visibility failures.  The fallout from these previous efforts can make resistance to new initiatives range from skepticism to outright hostility.  This may require some degree of sensitivity and outreach as well as thick skin to not take the tough environment personally.

Government projects can be a blessing when times are tough.  Due to the size and complexities involved, some of them can last for long periods of time, bringing stability in tough economic times.  While each project is unique and the above factors can be found on any project, these four factors can be particularly strong and surprising to those who have not worked in this type of environment.  A good contractor knows that it is important to understand the work environment, and while this is not an all encompassing list, these are factors some contractors have a hard time understanding on their first government project.

The old adage about things occurring in cycles seems even to apply to such abstract concepts as project management methodology.

As Prince2 has long been the standard way of managing projects it must take some  share of the blame for the failure of many high profile projects. As its framework is quite complex and places a lot of  emphasis on document creation it is not surprising that there is much interest in a newer methodology called Agile or Scrum which concentrates on quality, leadership and facilitation. Scrum also reduces resource wastage and ensures that projects are delivered on time and within budget by predetermining the cost, timescale  and resource needed and then dedicating 100% of that resource to the project, with no distractions.

During a recent presentation on Scrum I was struck by similarities with project management tools imported from the USA in the 1980s during my first encounters with Oracle systems. These  were Leadership through Quality programmes which introduced  quality circles and charts and promoted the need for quality and timeliness above all else when delivering projects. One particular analogy with Scrum was the belief in 100% success for every component before signing off a project as finished. This isn’t as ambitious as it sounds if compared to the manufacture of an aeroplane when you might settle for 99.99% of the components working perfectly, but if the plane has 1 million components there will still be 100 untested components present in the aircraft when it takes off.

Another Scrum philosophy is to test and test again after every code change, no matter how small. This was also the standard practice when maintaining the early Oracle applications where an untested change to program or system code could bring down the company database and maybe result in significant business impact.

There are currently a selection of courses advertised on the web where one can qualify for the impressive title of certified ScrumMaster, though I was not impressed when the one which appeared at the top of my search-list proudly advertised a 2 day course on ScrumMaster Certifiation. With Scrum being all about quality and getting it right first time a spell-checker might have been a good idea.  I guess this proves another old adage about  tools only being as good as the people using them.

Hi All, 

Please note Presentation Abstracts are due by the end of play today October 20, 2009: 11:59 p.m. EDT.

Abstracts will not be accepted after this date.

If you would be interested in submitting a abstract please head to http://oaug.collaborate10.com/presenterinfo/ to find out more.