First time visitors read!

If you are new to this Blog, read about it's purpose and how to get the best from it

Free Project Management Training

Go through the site content in a structured manner to teach you Project Management or improve your success rate

No English?

Can't speak English? No problem!!

Why the Sheepdog Analogy?

A Project Manager is a necessary evil. Why? Well, the PM doesn't produce anything - write code, lay concrete or whatever. However, don't have one and see what happens!

Always telegraph your Punches as a Project Manager

Sometimes as a Project Manager you need to throw a "Project Manager punch" but not a literal one please!

Isaac Newton's contribution to Project Management

Newton's laws, especially his first law of motion, should be as important to a Project Manager as it is to a Physicist. Why?

O Sponsor, Sponsor! wherefore art thou Sponsor?

You are given a project to run. Amongst your early questions should be, "who is the Sponsor?"

Always remember the Human side

It is very easy to get hung up in the technical and management side of Projects and forget that they need to be delivered by human teams. So "Always remember the human side" is the key phrase!

Why writing a Project Status Report is not a chore

I've met several Project Managers who view writing any Project status report as a chore. I think the opposite.

Planning is the key Project Management discipline

I have been asked a few times, "What are the top xx things to focus in on as a Project Manager? If pressed, I always fall back to Planning

Wednesday, 23 April 2014

Beware of bent spoons in your IT implementation!

A "bent spoon" is a very special risk I consider for any IT implementation. In this post, I reveal more about the derivation of this risk name and how to go about mitigating it. 
Project Risk - Beware of bent spoons in your IT implementation!
Before reading on you may want to look at my post on Risk Management first to understand the principles of Risks and how to manage them.

Uri Geller, the great bender of spoons

Uri Geller is a magician and self-proclaimed psychic. His TV performance which I remember involved him concentrating very hard and trying to bend spoons in every household cutlery drawer in the country. The audience was invited to phone in with the results and I was amazed that many people did. Now Uri may have skills I am not aware of but the scientist in me says that the most likely explanation was that the spoons were already bent but nobody noticed until invited to look?

Bent spoons in IT implementations

Most IT Implementations consist of a series of technical steps leading to the point in the cut-over plan when someone (typically a business person) is invited to "Live Prove" the implemented system and sign-off that all is well.

The Risk is that the live prover "spots a false problem" (i.e. a characteristic which is accepted functionality) and much time is wasted during the implementation event or worse case, this results in a "roll-back" decision. These are the bent spoons which need to be avoided if at all possible.

The Risk is most worrying (I suppose I should say highest probability!) when an existing production system is being upgraded as the old system is not available as a reference point during the upgrade process.

Mitigating the Bent Spoon Risk

My suggested approach to mitigate this Risk is to ensure that the live prover has scripted these checks to be performed as part of the Implementation plan and "tested" the script in the UAT (or other nominated) reference test environment prior to the cut over. Typically this should flush out any bent spoons before the actual cut over event with scripts modified as necessary.

So when you are planning your next IT Implementation / cut-over always think about Uri Geller and the Risk of Bent Spoons!!!

Tuesday, 8 April 2014

Environments KILL IT Projects

I have, in a previous post, implored you to attack the Risks before they attack your project. In this post I want to cover an area of risk which should be close to top of your attack list when running an IT project - Test Environments! Read on for my top tips to consider around this area of risk.
Environments Kill IT Projects

Environments are often key to IT Projects in that most likely you can't perform any software development without one and you will need others for the various testing phases in line with your agreed Test Strategy.

Check-list of Points to consider regarding the Environment Risk

Points I recommend considering with regard to this risk are:
  1. Establish early with your team what environments you need to deliver your project, are they existing or need to be built? Ideally this should happen during Initiation but if you can't achieve this (you won't have an agreed test strategy), make some assumptions and document these
  2. If environments need to be built, do you have the infrastructure or do you need to obtain new infrastructure?
  3. If the environments are existing, can they be dedicated to the project? Even if the answer is yes, make yourself aware of the other usages of the environment and probably this is a specific risk to be managed i.e. previous usage overruns. If sharing is mooted, be clear on whether this will be possible without impacting test execution
  4. Have a single owner accountable for environment creation and management. This person, the "environments manager" is a key member of your IT project team
  5. Establish what team(s) support the environments manager in achieving the role, sometimes people outside the core project team can be involved and this is an area of additional risk as there may be lead times, resource contention, difficulty in prioritising what you need etc
  6. Ensure there are clearly identified environmental requirements established for each environment. Normally the test manager creates these as part of test planning but sometimes the test plan is issued relatively near to execution starting and I prefer to establish these detailed requirements EARLY even if the test manager reserves the right to change control some elements
  7. Ensure there is a plan to meet these detailed environmental requirements. I don't personally want to maintain the plan myself just satisfy myself that my environment manager has it all under control. 
  8. The environment manager should send you a weekly report of progress towards meeting the requirements by the date agreed in the project plan
  9. For each environment, have an environment owner(s) - typically the test manager relevant to the phase of testing, SIT, UAT, OAT etc
  10. When the environment manager states that the "environment is ready", (i.e. the environment requirements have been met) the environment should be formally handed over to the owner
  11. Ideally the form of the handover should consist of a release note(s) - I like this formality. This can define if all the environmental requirements have been fully met (and any observations from the technical team) and in terms of code releases, what is the release number(s) of each software component, known defects etc 
  12. I normally plan for 1 day of smoke testing to be defined by the environment owner. The purpose of this testing is to get a view quickly whether the environment is fit for purpose. It doesn't mean that other issues won't come to light later on during testing but it is a good indication
  13. The results of the smoke testing are included in any Test phase ENTRY meeting as one of the criteria
  14. Once entering the test phase, no change to the environment should be made without the agreement of the environment owner. This includes code releases or anything else that may affect test results
  15. Ensure there are clear configuration management processes and owners. 
  16. In terms of code configuration management, are there code branches and are the development team correctly merging between branches e.g. are production fixes being retrofitted into the project branch(es)
So hopefully this check-list of points will help you better manage this key IT risk area. I keen to add to this list - do you have any suggestions?

Twitter Delicious Facebook Digg Stumbleupon Favorites More