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?


Post a Comment

Twitter Delicious Facebook Digg Stumbleupon Favorites More