Project Risks: Governance – Too Much, Too Little, Too Late

Travelling around different clients, with different objectives; different risk appetites; the one question that always comes up is related to Governance.

Irrespective of what Methodology your project is following; be it SCRUM, Waterfall, SCRUMFALL, there will always be a stakeholder or two that will want to know exactly what return on their investment they are getting. The title of this post includes the phrases “Too Much, Too Little, Too Late”; I am going to outline my views on each of these situations and the potential impact each has on the project lifecycle and perception of the stakeholder.

 

“Too Much”

At first glance this seems a little counter intuitive; surely demonstrating full control of the project via the medium of metrics can only be good? To a point yes; but this is a case of knowing your audience. What happens if your project is only one of a wider portfolio that your stakeholder has budgetary responsibility for? Too much detail, may lead to disinterest or confusion. Key messages may become lost in the countless graphics and metrics.

To avoid this situation; it is imperative that boundaries and expectations are set as early in the project lifecycle. Agree the format and detail level with your stakeholder, ensure that they are engaged from the outset so that week on week you are providing decision grade information to assis the stakeholder to manage risk within the project.

“Too Little”

Again this seems an obvious statement, but sometimes when you are in the detail or under mounting pressure to deliver; these relatively “simple” steps can be overlooked. So what can happen in this situation? Well, depending on the vision and focus of your stakeholder, a lack of governance, can lead to the perception of panic or rather lack of control in your project space. Not having to hand the latest defect trends, the latest execution numbers will not install confidence that there is control within the project. If governance meetings are scheduled and there are conflicting messages being delivered from each of the project teams, the battle is lost. Stakeholders losing faith in their project team could be an ominous precursor to budget reductions and smaller releases, to reduce their “perceived” risk exposure.

Setting the boundary and expectation upfront, will provide the foundation to provide key messages during the project lifecycle. Delivering bad news in a controlled, consistent manner; though not necessarily welcomed; will still maintain confidence in the project team, decision grade information will allow options to be explored, mitigating risk where appropriate.

“Too Late”

Trying to apply governance when things start to go wrong, or after stakeholders have raised concerns with delivery is risky. Introducing governance in this situation could lead to the perception of the team being “Reactionary”. the stakeholder may feel that they need to follow closely ‘progress’.

In this situation, I believe the key is too start small. Introducing one or two measures to overcome the ‘reactionary’ tag, to increase confidence with stakeholder is key. Once the value is demonstrated, the team can work with the stakeholder to increase the level of decision grade information, to regain faith that project team is working in partnership, and is in control.

In all of these situations, the key is communication; which is often overlooked as a matter of course. Setting the expectation upfront, will ensure the level of governance is acceptable. Agreeing format and data collection tools is also key. Governance should be useful project tool, rather than a massive overhead and an invitation for criticism. providing good and bad messages on a project are par for the course; both messages need to be delivered with confidence and consistency to ensure stakeholders remain confident; giving projects the best chance to succeed

 

 

Project Risks: Error Handling and Estimation

Having worked on numerous high profile projects, it is still surprising to find push back from stakeholders and delivery teams not to include dedicated story points and capacity for the not so ‘sexy’ error handling and UI error / warning messages from iteration (sprint) 1.

With the growing acceptance of adding UX design to the project team, providing the vision; through the creation of design prototypes that help secure budgets and buy-in from stakeholders, many of these design presentations concentrate on the happy path scenario only. Story backlogs are created, estimates generated and iterations sliced and diced giving everyone a sense of we can do this, with a clear; agreed roadmap in place.

Sound bites such as ‘Minimum Credible Release’ are likely to be shared, pats on the back, high fives and talk of just how big the bonus will be; may become common place.

But what happens on the run in to production implementation? End to End system testing starts, or worse UAT, tests are passing, confidence rising… Then Bang! A downstream system goes down for maintenance, no body knew on the project team…. The UI can’t cope, starts crashing at will, those in the business responsible for UAT are now panicking as its 2 weeks until launch and the platform is not stable….. That bonus that was a sure bet that morning is starting to move from a deposit on the Ferrari to a child’s toy Ferrari…. How could this of happened????

No-one thought about the what-if scenario, all hands to the pump… We must go live in 2 weeks (I at least want to test drive the Ferrari!)!!!!! This is where Project Management need to ensure that during project initiation and backlog creation; the definition and estimation phase should include representation from a variety of functions such as; QA, Business Analysis, Development and business. Taking the UX design, should lead to a decomposition of each functional area. All of the integration touch-points need to be clearly defined in order that resiliency or error handling stories can be captured from which the QA team can define suitable acceptance tests to aid the in-sprint development and testing.

Taking the time up-front to fully size stories for the functional and non-functional requirements; though increasing the initial estimate, should help to reduce risk factors and potential failure points; especially in the run up to production implementation. There is likely to be pushback from the business from the outset, as estimates are increased, and it is difficult for the stakeholders to visualise the value that is being added to the system. The project team will need to provide a solid case for the investment; calling upon previous experiences and championing the case for the production support team to minimise outages once the product is deployed to production.

If these unhappy paths are not included from the outset, those teams that are “Agile” (quotes intentional!) will soon be forced  to support production maintenance, likelihood is that ‘special’ teams boldly given names such as “Rapid Response” or “Tiger” are likely to be formed; tasked principally with ensuring the production environment is stable, and resilient to failover. Creating such teams will impact the project teams velocity against the delivery roadmap; which the stakeholders have provided budget for.

As with all projects; there is likely to be a trade-off; it is very unlikely that a project team will be able to code for all eventualities; the stakeholders may have a high appetite for risk and may decide not to invest fully in unhappy path resiliency. However, the exercise is still a useful tool to use to populate the backlog. Architectural analysis should quickly highlight the main project / integration risks in order that mitigation plans can be agreed sooner, engaging downstream systems earlier should assist the co-ordination of production release dependencies; thus reducing risk still further.

In summary, learning from mistakes to make the next phase / project better is the goal. Providing a robust and resilient system to users and stakeholders will raise confidence in the platform; which will be useful at budget allocation times.

 

 

 

 

Favourite Tweets – January 2012 (via @obofdis)

Over the last month, there have been quite a few tweets that have caught my eye, and I have retweeted, below I have summarised those that I thought were worth a read.

Agile Project Management

1.  (via @solutionsIQ) New post: When the bottleneck of an #Agile #team is the team itself http://ow.ly/8EDia Dealing with dysfunction #pmot
2. (via @PMVoices)How do you maintain your integrity while managing a #project? http://ow.ly/8CTsS
3. (via @PMVoices) When a #project is finished, how do you evaluate the lessons learned? http://ow.ly/8CTcH #pm #pmot
4. (via @PMHut) http://www.pmhut.com/a-return-to-agile-basics-part-1 Return to agile basics
5. http://ezinearticles.com/?Estimating-Agile-Software-Projects—How-to-Stay-Within-Budget&id=1107433 estimating #agile software projects, how to stay within budget #pmot
6. (via @johannarothman) on why Agile Project Manager is not a Scrum Master, especially on distributed teams. So very true! #ya…http://lnkd.in/7a-8Gi
7. (via @PMHut) Bad Language in Software Projects http://www.pmhut.com/bad-language-in-software-projects (a very funny and light reading for project managers and IT professionals)
8. Reading http://www.projectsatwork.com/content/articles/267610.cfm Technical Debt for PMs

Testing / QA

1. Currently reading http://bit.ly/xBePRJ – Devising a test automation strategy: Getting started
2. Implement a test tool and platform agnostic automation architect http://bit.ly/A5guY1
3. (via @agile_coach) Does your software team create a lot of bugs? Then your process is defective. #agile #testing http://bit.ly/xMCyhf

General

1. http://kief.com/continuous_delivery/continuous_delivery_vs_agile.html Conflict between continuous delivery and Agile
2. (Via @Goyello) Key challenges in Agile implementations http://tinyurl.com/7j6tbks
3. 5 Signs of a Great User Experience http://rww.to/zR08nQ
4. Do you follow these rules? The eight simple ways to build customer loyalty. Top story on @LinkedIn_Today via @INC http://ow.ly/8MESS
5. 10 Signs that Your Team Isn’t Really Agile http://ow.ly/8N6DE Good list from @stoneass
6. (via @solutionsIQ) Agile is evolving, not declining http://ow.ly/8Rpxy Forrester: Blending Agile, non-Agile techniques/practices => hybrid methodology
7. (via @ScottOstby) Branching and merging: the heart of version control – Software Development Times: http://sdt.bz/36328 via @sdtimes #Agile #SCM #algorithm
8. http://blogs.collab.net/agile/2011/12/19/where-do-we-credit-work-done-on-unfinished-backlog-items/ Where do we credit work done on unfinished backlog items?

What cost a lack of acceptance?

Having worked over many years on various sized projects, similarities can be drawn irrespective of who runs the project, what the business priority is and how much budget is available. Wherever you go you are likely to face the same issues or anti-patterns when it comes to process and approach.

The focus of this blog post will be the Agile sprint process, moreover what prevents us achieving near “Production Quality” code at the end of a sprint and how in turn that code becomes “Production Ready”. I will be looking at some of the main barriers to achieving this status, and outlining where things should change, to give the project team the best chance of success.

Before going into detail, I’d like to start by explaining what I mean by “Production Quality” and “Production Readiness”:

Production Quality – I see this as the minimum acceptable level for any code package delivered at the end of a sprint cycle. To achieve this production quality, I assume that before the sprint, an inclusive game-planning session was conducted, where the scope of each story was agreed, and the acceptance criteria (inclusive of tests) were defined in agreement with the Product Owner. The “Quality” is determined, by the fact that the project team has developed and reviewed the agreed stories within the sprint, meeting all of the acceptance criteria. By achieving this, the project team are suggesting that there is available a Production candidate that can be handed over to pre-release QA and / or Business Acceptance Teams (UAT) for validation.

Production Readiness – Once the release candidate has been subjected to ‘an appropriate’ level of QA and UAT analysis, if no blocking defects have been found, and all of the functional and non-functional requirements have been validated, we can label the package as “Production Ready”. The package can now be handed over to the Release Management team, in order to schedule a deployment to Production.

Now that I have clarified what I mean regarding quality and readiness, I’d like to address the title of this post “What cost a lack of acceptance?”. If elements of the sprint process are ignored, or overlooked, whether to save time, money or to get things done; the impact can be quite high. In my opinion, these thought processes are a false economy, as you are potentially shifting the issues later in the development or release cycle; which as we know from traditional analysis; the later in the lifecycle you detect a defect, the greater the cost is to fix it. So what pressures can be experienced, that can lead to a lack of acceptance?

1. Development Versus QA Ratios - Inequality within a project team with respect to the ratio of QA personnel to that of the development team can have  a significant impact on the ability of the QA team to keep pace with in-sprint tasks (such as defining acceptance tests for future sprints and providing daily feedback during the current sprint) whilst conducting more traditional QA tasks; such as release candidate testing. If this situation arises, it is likely that a trade-off may need to happen. One such trade-off could be to reduce the amount of acceptance criteria on a story. If this happens, we could be adding risk to our release schedule as only limited validation has taken place before entering final QA; leading to more bugs being found during QA, requiring additional builds and retest cycles. Having to pull developers off of in-sprint duties to fix defects, raises the cost to the project. Not only in terms of time to fix (and merge to code branch(es)), but also the potential impact their withdrawal has on the current sprint.

2. Waterfall in a sprint – I have worked on projects, which claim to be Agile, which on inspection stretches the truth just a little! All that happens is work packages are split in to 3 weeks, the developers code for 2 – 2 1/2 weeks then ‘throw over the fence’ to the in-sprint QA for testing. Adopting this approach, does not maximise the potential gains of providing regular (daily?) feedback from the QA team. The earlier in the sprint issues are found; the quicker they can be fixed, raising the perception of quality on a daily basis.

3. Lack of Product Owner buyin -  If your product owner is not fully engaged with the project, this can lead to a lack of acceptance. If the Product Owner does not provide (or at least provides input) the minimum acceptance criteria at the beginning of a sprint, the team will be fighting a losing battle, as come the walkthrough at the end of the sprint, any vagueness will more than likely have been interpreted incorrectly, and thus the Product Owner may insist on instance fixes to resolve before providing sign-off for the feature in question.

5. How integrated should you be? -  If during a sprint the acceptance criteria, overlooks particular integration dependencies; including the target go-live dates of dependent systems, this could impact the projects attempts to achieve production readiness. A lack of understanding of release schedules for dependent systems can lead to reputational loss of the project team with sponsors; as features will be unusable in production, thus preventing the company from rolling the product or feature out to prospective clients.

I have experienced all of these pressures on various projects over the years. They are always likely to come up during software delivery projects; but it is how far they are allowed to manifest themself; that will determine the size of the impact that they will have. Keeping control of these factors, should increase confidence, and promote knowledge within the team. In order for the team to succeed, it is how these influences are handled, and how close the team sticks to the agreed approach, which will play a significant part in determining whether the delivered product is fit for purpose. Keeping control on acceptance criteria, from clear definition through to implementation will provide one of the key factors of project success.

 

Pragmatism Vs Optimism – Releasing Software

With the recent downgrading of the US credit rating, and the on going commentary regarding the potential double dip recession; businesses; including banks are feeling the heat and are displaying caution; particularly with regard to IT projects and the risk releases have on existing revenue streams.

What affect does this caution have on IT? Well, if the cautionary stance is a prolonged activity and you are working in a fairly established project team; budgets are likely to be reviewed. Rather than new development, the emphasis may switch to that of a maintenance agreement.

If you work on a greenfield project, these market conditions will have various impacts depending on:

- Risk Appetite of your sponsor(s)
- Stability and availability of your non-Prod environments
- Value proposition of upcoming feature delivery I.e. Can the company sell it!

If your company has invested heavily in your project, the optimist will come to the front and lead, direct and hopefully motivate your team to deliver high quality software, that when marketed has the potential to make the sponsor money, whether through shares or bonuses.

If you are already ‘live’ and are working on a feature release, stakeholders may adopt a more pragmatic approach to software delivery. They may decide to delay releases to protect reputational risk position. An undetected bug in the new feature may dissuade clients from using the platform, and thus impact potential revenues. Other forms of pragmatism may include soft or internal launches, to minimise exposure and thus reduce risk; whilst maintaining traction on delivery pipelines.

It is a fine balancing act for project teams in these periods of volatility, too cautious an approach, and you lose ground against competitors, or your stakeholders reduce budget due to lack of delivery. Too aggressive an approach, and if things go wrong the product loses its reputation, and prospective clients are cautious of using the platform; due to a perceived lack of quality.

To ensure projects survive and maintain velocity; open communication between project team and sponsors is essential. Clear messages outlining progress; coupled with a concise outline of risk and issues (with associated impact) will provide essential data for sponsors to make decisions in line with their risk appetite. Taking the view from various parties; such as service management, should build a clear picture of the risk to deployment. Agreeing various SLA’s for production candidates, should be a matter of course, however these become imperative, when seeking approvals.

Can Agile beat the ‘inevitable’ Death March…Discuss

Having worked on various projects over the years, with the main driver being time to market pressures, I thought that working as part of an Agile team, the days of the death march were over as we agree our work packages upfront.

Currently, I am working on a project that is going all out to meet the deadline, at the expense of agile approach. Though it has it’s moments of chaos, the job is getting done.

This leads me to the topic of this post. What are people’s views on the death march approach, is it an inevitable consequence of changing business demands? Or can agile fight it’s corner and prove it’s flexibility, to deliver to change in focus?

All comments / views welcome

Continuous (Process) Improvement – How Often & How Much?

Reading and practising agile within a team, the aim is to promote collaboration and commitment to delivery on a sprint basis. Process improvement is what all team’s should strive for, making the process ‘lean’ will allow the team to take on more work or deliver increased complexity. I’ve come across a couple of interesting articles, that highlight the case for doing something and the case for doing nothing until you have a question to answer.

The first article from tool vendor VersionOne – http://bit.ly/drDGUG highlights the need for constant improvement to keep the process fresh.

The second article My Flexible Pencil – http://bit.ly/9dj2pD shares a different view, that sometimes doing nothing is the ‘best’ thing that could happen to the process.

From my point of view, I’ll take a few splinters, and sit on the fence with this one; though if I had to commit, I’d probably fall on the side of My Flex Pencil.

The important thing for me is that process change has to be worthwhile, and display a tangible benefit to the team; whether that be reducing admin overhead or encouraging collaboration through workshops. The outcome of retrospectives is an important one, small; achievable tweaks to a process on a sprint by sprint basis should easily show tangible benefits. Vast overhauls of process, can lead to the dangerous position where team members become lost; in turn affecting delivery.

So in summary, ‘how often’ should be driven by the outcome of retrospectives. ‘How much’ depends on the evolution of the team; has the team ‘outgrown’ the current process? If yes then a major overhaul maybe the answer. If no, the retrospective tweaks may be sufficient, but the team will decide…..