In our experience helping clients with compliance projects, we’ve noticed some fundamental aspects in which these regulatory change initiatives are different from other business-driven change initiatives. We thought we’d share 5 of the most distinctive differences, which you might have already considered in Eva’s struggle.

Drop dead dates

Deadlines are fixed and set externally.

In regulatory projects the deadline is fixed by the regulator and individual firms have little influence on implementation dates. There have been instances when the initial deadline has been so tight that no market participants could meet them. In these situations the regulators may be forced to re-consider, but this isn’t commonplace and generally organisations have far less room to manoeuvre timelines in regulatory projects than in business-driven projects.

Poorly-defined requirements

Requirements remain uncertain until late in the game.

The winds of a change in regulation are often felt well before the deadline. But unfortunately the devil lies in the details. After high level drafts, there are consultation periods and it can take years to produce the detailed technical standards. Meanwhile the implementation deadlines remain fixed. Firms can start projects to implement the changes, but until the final text of the regulation is produced the industry can only make assumptions about what the final guidance will state. This is contrary to an ordinary business project where the traceability of requirements is carefully managed and all changes go through an acceptance process before being applied.

Everything is “must-have”

There’s a fixed list of requirements to implement.

Regulatory requirements define a mandatory set of functions. Everything is must-have and this could be a serious hindrance in any project methodology.

But how does it affect the iron triangle of project management? We’ve already spoken about the time and features elements, which are fixed to some extent and this is different from the traditional methodologies.

Figure 2 The regulatory shift in the iron triangle

You might already be familiar with the waterfall and agile versions of the triangle. The regulatory one is probably a blend of the two as you can see from the third picture. The only factors you can really influence are cost and quality. Everyone would like to decrease the former while increasing the latter. But the elements move together, they are inter-dependent. Assuming that the planned solution is optimal, if you reduce the budget, some of the other elements will have to move down with it. Create a partial solution or run out of time and you’ll surely face huge fines. The only viable choice for reducing costs seems to be reducing quality. But whose choice is it?

Who is the business owner?

When no one wants to be.

By interpreting the legal text, Legal or Compliance becomes the “source” of requirements in regulatory projects. But, not every organisation is prepared for that when it comes to project governance. After identifying the affected systems and processes, the impacted department becomes the official owner of the project. But are they truly engaged in this mediator role?

If you think about how regulatory changes usually take the resources from business initiatives, it must be hard for the owners of those shelved business projects to wholeheartedly support the unexpected guests. But these projects desperately need the engagement of business, because compliance can only advise of the final state, but not how to get there. That capability lies in the hands of the business users.

Now how does this affect our project planning triangle? Resources are scarce; the cost has to be minimized. This seems to be reasonable for a project which does not bring direct benefits for the organisation or the investor.

The argument is questionable on two fronts. When we speak about direct benefits, have we considered the fines which we don’t have to pay if the project is successful? This might not be a strategic benefit and as a best result we just maintain the status quo. But avoiding costs is as important as reducing them, not to speak about the reduced risk brought by the regulation. On the other side, with respect to minimising costs, which costs are we talking about? The immediate costs of executing a project until the deadline or the total cost of the change, which potentially includes years of manual work instead of automation? Additionally, what about the costs associated with the maintenance and operation of new systems as well as future changes? And the list continues with the financial consequences of being shut down by the regulators.

If we blindly minimize immediate costs, we’re risking the reduced quality of the solution which will increase costs in the long run.

Quality is the fourth perspective from which the legislation usually doesn’t define how the change should be implemented. Should you use automation or manual processes, develop an in-house solution or integrate a boxed product? There are lots of decisions about quality which can be and must be made carefully in a regulatory project.

Everyone is equally affected 

You might be fooled into thinking that the same regulation affects everyone in the marketplace equally. But are all participants equally impacted? In our experience the depth of the effect on resources and the business can be vastly different. An organisation which has its compliance eye on its processes may be better prepared and can therefore focus more on advantageous projects. Therefore it’s important to watch the regulatory horizon with eyes wide open and to be willing to adopt a culture which supports proactive thinking about the possibilities. Meeting the regulatory requirements should be the consequence, not the driver of a thorough organisational risk culture. Look behind the tickboxes.

The post Regulatory projects are commonplace, but should we give them special treatment? appeared first on BSG (UK).

The post Tackling the fallacy of agile appeared first on BSG (UK).

Challenges are just opportunities to think differently

Offshoring has its horror stories. Many of them resulting from putting the desire to drive cost down ahead of the desire to deliver against business benefit. Throwing specs “over the fence” may be cheap, but there is often significant business upheaval in the wake of a poorly built software system. The cost of correction (in the software) and disruption (in the business) is often significantly greater than would’ve been incurred had a smarter approach to working as a team been pursued from the outset. Effective collaboration within distributed development teams is thus becoming increasingly important.

We recently conducted a lessons learned exercise on a project in which we built a reporting tool for a London based insurance market corporation. The team was split across London (business design) and Cape Town (software development). The system, which has approximately 100 users, extracts, collates and submits data from multiple sources to a regulatory authority. Inspired by the lessons learned exercise, and building on our collective experience across a number of distributed projects, we want to share our reflections which all sit in the realm of collaboration.

Teamwork begins best in person

It would be naive to ignore that the best way to cultivate effective working relationships is face-to-face. Ideally, the delivery team should meet in person at the outset. Sometimes it’s not possible for the business users to be involved in this. On this project, the business analysts, after having spent time understanding the business’ ambition, hopped a plane and spent some time with the development team with the aim of clarifying the requirements. I hear Cape Town in March is spectacular.

Collaborate on estimating and planning

No matter how experienced the Project Manager, there is no point in planning without the involvement of the team responsible for delivering the product. Expecting team members to take accountability for their delivery requires suspension of a degree of control in setting the estimates.

We found that delegating estimation at a task level to those responsible for task delivery helps to create ownership and accountability. It also creates a feedback loop: plan the work, do the work, reflect on the plan and improve planning capability. The best estimates are sense-checked by peers to ensure that the team are not setting themselves up for failure.

Share the plan

It almost goes without saying that once the plan has been compiled, it should be shared with the entire team. We recommend that this take place in a forum where people are encouraged to raise concerns such that they can be understood, addressed and either dealt with up front or influence the subsequent planning. This will ensure that the team is committed to achieving the objectives of the project.

Adjust working hours

So as it turns out, offices on either sides of the planet often exist in different time zones. Go figure. A simple way of resolving this is to align working hours across the team in a reasonable fashion (i.e. create a set of core hours when everyone on the team is working). That way when Sarah identifies a bug during system testing at 15h00 in London, John can be reasonably expected to respond, even though his local time in Bangalore is 20h30. The key here is to set expectations across the team (including external stakeholders) upfront.

Stand up

Make sure the team keeps talking. One of the most effective ways to keep one’s finger on the pulse is to meet at the start or end of each day for 15 minutes. The purpose of this is to provide an overview of what was completed the previous day, what will be tackled the next day and to raise any burning issues which are holding team members back from progressing. It’s a well known practice across agile delivery methodologies and our experience reiterates its importance.

Talk more

Despite the natural gravitation towards email and/or instant messaging, we found that the best way to avoid ambiguity was to pick up the phone. A message sent is not necessarily a message understood, but a message discussed is far more likely to be. Better yet, we used video conferencing to discuss product features and ensure that the development team understood exactly what was meant by each requirement. There is significant richness in real-time personal conversations.

Use the right tools

Finally it’s important to use the right tools which enhance a collaborative working environment. We’ve already touched on the use of video messaging (we used Google+ Hangouts) and instant messengers, but there are a plethora of online project management tools becoming available. These allow users to allocate tasks to individuals, ensuring there is transparency (i.e. everybody knows what has been assigned to whom) and task ownership (i.e. the person to whom a task has been assigned is responsible for its completion). We’re currently experimenting with Asana, but different teams will find different tools are productive for their working practices.

These ideas and techniques allow the whole team to have early sight of any potential problems which can then be addressed proactively. The approaches also engender a culture of sharing where team members are encouraged to speak up sooner rather than later. The simple things are often the most constructive.

What practices have you found helped you to overcome the challenges of working in teams spread across distributed geographies? We’d love to hear from your comments.

The post Collaboration: The key to successful distributed development appeared first on BSG (UK).

Human nature inherently means that we want to be heard and have our opinions counted. If our thoughts are not listened to, we tend to feign interest regardless of the outcome. Politicians need to listen to a wide, diverse range of individuals when they want to pass new laws or make amendments to bills and the way that they track these conversations is by writing things down. They write lengthy documents in order to ensure that their point of view is clearly understood, which in turns facilitates a process of analysing and commenting which makes the law more widely palatable.

Now while I am not saying that documenting system requirements is as important as passing legislation, I have worked in enough large organisations to know that politicking occurs as much in the boardroom as it does in Westminster or on Capitol Hill. On software development projects there is a regular need for business analysts to play the role of ‘cowboy’ in order to obtain project success. And the only way to successfully ‘herd’ humans is to listen to them and to let them know that they have been heard.

Herding cattle is all about communication

I’ve yet to see a more effective way of sharing ideas and obtaining input from across an organisation than the BA practices of holding workshops, documenting the outcomes and reviewing the documents. If documented correctly, the ideas and requirements of the system can be objectively seeded across the company (there needs to be a culture within the organisation of reading documents, but that is a topic for another day).

A clear specification is a lot less open to interpretation than subjective word-of-mouth conversations – something that is written down cannot easily be changed to cater for the whims of different audiences. A clear specification proves that you heard what someone was saying, internalised it and then articulated it back to them. As enterprise social features become more prevalent in the workplace requirements may move out of offline documents into online forums, but they will still be written down and documented.

Communicating with larger groups of stakeholders is difficult

In documenting requirements one opens up the project to comment and analysis. In small teams, commenting can be done through conversations, and Agile comes into its own because the team would not twist words to mean something different. Business stakeholders and the development team are co-located and the focus is on discussion, resolution and implementation. Documentation becomes less important.

In large, complex political organisations ideas need to be seeded widely throughout the organisation in order to obtain buy-in. Often many different business units need to provide input into the changes so that their future work is not adversely affected and so that they have the opportunity to benefit from the project. It is not practical, nor feasible, for one or two business stakeholders to represent requirements across such a large community. It shouldn’t be a question of whether documentation is required or not, it becomes a question of how the documentation should be represented to best suit the project.

Agile vs. comprehensive documentation – a standoff?

In my experience working across many large organisations, people are listened to in the workplace – flat organisational structures allow for everyone to have their say. Because of this, large companies are susceptible to internal politics. Wherever there are lots of people vying for prioritised requirements, politicking will occur. A BA should be objective, and the best way to remain objective in multi-party projects is to write things down.

The Agile Manifesto states that working software should be the focus over comprehensive documentation. While I wholeheartedly believe in working software, I also believe that while roaming the dusty plains of requirements gathering in large organisations, comprehensive documentation is vital to appease all political parties.

This article originally appeared on Bridging the Gap on 30 March 2011. Click here to view the original article.

The post Do workplace politics destroy Agile principles on documentation? – Ryan Knapton appeared first on BSG (UK).