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).

It amazes me how often this perspective gets overlooked, never at the outset of the project of course. In the heady early days, it’s all about benefits models and the associated business case. It’s usually once the project gets underway that the focus slowly shifts from talking about why something is being done to what needs to be done.

We should know better

It’s not as if we – as a collective industry of change practitioners – don’t know what constitutes best practice. PRINCE2® teaches that projects deliver outcomes, not benefits. At the outset of the project, it is important that the benefits case is clear around when benefits are expected and – the bit most often overlooked – how they will be measured and reported on in the absence of a project structure.

Once the project gets underway, a collective madness ensues. Project plans are baselined and the team begin focusing on the deliverables. Little-by-little the deliverables of the project become the end themselves, rather than a means to an end. The project team gets caught in the trap of focusing on completing project products (i.e. the what) rather than remembering the project’s cause (the why).

All too often we see stage gates reviews that the relevant documentation has been produced on time and to some notional quality standard. It’s not often that I’ve seen gate reviews do a genuine and meaningful assessment of whether the content of the documents is meaningful in the context of the project benefits.

Time is of the essence

Is it a matter of time? Typically the effects of a new system will be felt in a specific cycle. There will be an initial surge of activity driven by the project and the newness of the implemented change. People will take it for a test drive and kick its tyres. After a time, some sort of normalisation will take place when people either feel it is in their best interests to continue using the new system or they will fall back on old habits. The nature of the project will determine the length of the cycle.

The actual realisation of the benefits only comes much later, typically once the project is already shut down. The project team have packed up their laptop bags and moved onto bigger and better things and there’s no-one around to look after post-project activities. In reality, this is the most sensitive time in determining a project’s success. It’s only now that it can be determined whether the project has begun to deliver the benefits it set out to deliver.

Fooled by the plan

Strangely, the buyers of change don’t seem to be hopping mad about this either. They too succumb to the focus on deliverables. Delivery becomes the measure of success rather than objective review of whether the project has delivered the benefits it set out to achieve.

Hopefully buyers of projects have made their investment decisions based on the value of proposed benefit against the proposed project cost. Why aren’t they demanding evidence of value for money? Frankly, I don’t know. I do know that in the bulk of clients I’ve observed in 10+ years of IT consulting, benefits reviews are very rare. Rarer still are those that bring conversation around benefits, design imperatives and project objectives into the daily culture of the project.

I’m not against good planning. I’m not even against sticking to the plan. I’m just against task focused project teams perceiving the need to deliver product x against deadline y as more important than delivering the benefits that the project set out to achieve.

Key takeaways

So what should be done differently?

• Ensure that the project is based on a robust benefits case;
• Ensure that stage reviews have meaningful assessment of the content in the project products;
• Ensure that the benefits case includes a mechanism to monitor benefits after the project completes, and that this mechanism has an owner who takes accountability for operating it;
• Ensure that the BA, PMs and project sponsor create a culture where there is talk about the benefits of the project rather than just the deadline;
• Ensure that project sponsors hold the delivery team accountable for delivery of the benefits (this requires post-project monitoring and appropriate mechanisms for holding people accountable);
• Ensure that benefits are measured after an appropriate time is allowed to ‘bed the change’ rather than as part of the project shut-down activities.

This article originally appeared on the BCS Guest Blog on 22 June 2012. Click here to view the original post.

The post Blinded by the plan, ignoring the benefits – David Reinhardt appeared first on BSG (UK).

A business case should be a living document. Benefits need to be defined in the early days of the project and, on an on-going basis, the likelihood of delivering the benefits should be assessed. PRINCE2® advocates this is done as part of each stage review. More importantly, after delivery of the business change, it is important to monitor benefits for as long as the business case model implies in the payback period.

The post Benefits realisation is about more than just project delivery appeared first on BSG (UK).

The post Business Analysts make the best Project Managers appeared first on BSG (UK).

The post Agile projects cannot be successful without business analysts appeared first on BSG (UK).

Evolution is key to the survival of any species. This isn’t a revolutionary concept; it has been around since man moved from eating raw meat to finding his first source of heat and energy. In business, the same is true. Those still using caveman techniques in a world evolving around them are likely to become extinct like the dodo.

There is clearly a need to constantly adapt, to realize that if one approach doesn’t work that it isn’t the end but rather the beginning. There is a need to recognize that you do not know all the answers, but collectively, those around you may.  This ability to adapt, to change tack at will and collaborate with others is what distinguishes the business analyst profession.

The post Implementing Change – Catherine Perks appeared first on BSG (UK).

Now naturally we both believe in the benefits of teamwork, however sometimes I find that I can get things done faster if I do it on my own. In this article I don’t want to explore how delegation should occur on BA teams (that is for another day, and requires a different skill set).

Instead I want to pose the question:

When is coaching fellow BA’s a hindrance to the overall success of a project?

In the majority of instances, coaching is important

Coaching is an important aspect of growing team members. We all learn from each other, and different experiences make us better analysts. Coaching benefits both parties, the coachee learns more efficient skills, while the coach receives a number of softer, qualitative benefits and also learns skills around communication, expectation management, delegation etc.

The coaching process improves the organisation too. It creates better BA’s within the company, whether those BA’s are part of permanent or virtual teams. Future projects will be better managed and analysed because the overall skills within the organisation have increased. But what about a current project?

What about the minority of instances?

Coaching takes time and unfortunately not many people have the luxury of learning outside of the job. Of course there are examples, many of which are addressed on this site under the ‘Help a BA’ section, where coaching is done outside of the job. But that is different to on-the-job coaching. What happens if you could get things done faster without having to coach someone? What happens if you could get a task done in half the time it takes a BA who is learning something new (soft or hard skills)? Some projects have extremely tight deadlines, such as when a new legislative act brings about changes to core processing systems. Can coaching really be possible on every project?

Please don’t misinterpret what I am trying to say. I wholeheartedly believe in coaching. I think that it is an essential aspect of team dynamics. I would just like to debate whether it is always appropriate, and whether certain projects can afford to have BA’s coaching other BA’s. Of course not all projects will actually result in any coaching taking place (as not all projects will have BA’s learning new skills), but where the possibility does exist, I wonder if it’s worth asking the question: Can this project afford for any coaching to take place?

This article originally appeared on Bridging the Gap on 14 July 2011. Click here to view the original article.

The post When does coaching become detrimental to project success? – Ryan Knapton appeared first on BSG (UK).

I wouldn’t expect much “umming and ahhing” if I alleged that there was considerable value to be gained in building strong relationships with stakeholders. It seems almost logical that building robust connections brings with it not only commercial benefit, but also project benefit. It instills a sense of teamwork as opposed to the typical “us and them” scenario. Strengthening relationships inadvertently means building an understanding of a person’s background.

Some facets of a person’s background can be researched, interpreted and assumed. I’m not attempting to create a foundation for über-prejudice, but it’s fair to say that when working with team members from other countries, a simple Google search or picking up a decent guidebook / travel book affords you valuable pointers on general customs and beliefs of a population. I appreciate that some of these facts may not apply, and that members working in a particular country are not necessarily originally from that country. However, having this information at hand does not hurt.

Researched characteristics can equip you for better planning

With the rise of global organisations, it is becoming more and more common to be part of a cross-border, and specifically cross-timezone, team. To give one example of cultural difference, I worked with a team where members from one country believed that working long hours in order to get the job done made you a better employee. Members from another country argued that having a good work-life balance enhanced productivity and reduced long-term fatigue.

In my experience, this often becomes a point of contention when things don’t go according to plan. This isn’t a debate about which is correct or more effective, but rather a discussion around understanding, appreciating and embracing cultural differences and using this to the advantage of project planning. Having an understanding of these working habits early on, means that better resource allocation can take place. Tasks assigned to employees who work a stringent 7 hour day may take longer than tasks assigned to employees working an 8 hour day.

Some characteristics – similar to the example on cultural difference above – can be researched. I recently read a guidebook on the United Arab Emirates (UAE) and was intrigued to learn that this type of information was readily available. I believe that, as far as possible, such characteristics should be taken into account during project planning. How and to what extent they are taken into account is up to the planner.

Going beyond skin-deep takes time, but enables you to fully leverage team member skills

Building rapport with stakeholders is about occasionally flaring from regular project tête-à-tête to associated personal experiences and stories. This opens the door for understanding similarities or dissimilarities between ourselves and others. It gives us an opportunity to learn about those attributes which cannot be researched, such as previous experiences, personal skillsets or even individual strengths and weaknesses.

I have been privileged to work with teams that have not only been culturally diverse, but also experientially diverse. An individual’s experience is clearly something that cannot be researched, but can be learned through the building of a strong relationship.

The benefit of having greater insight into an individual’s experience or skills is that these factors can be considered during project planning. Knowing that an individual is familiar with a specific aspect of a project means that their experience and skill can be leveraged. This does not only allow for better resource allocation, but also means that the individual can be consulted to provide recommendations on timeline estimations.

Something to consider here is the time ‘cost’ of getting to know an individual, versus the benefit of improved project planning.

Characteristics of newly promoted leaders may require additional schedule buffers

On one project, during a scoping and planning session, I was informed who my stakeholders were and covered the pertinent bases around level of seniority and experience. Regrettably, something that wasn’t as widely covered was the duration that some of them had spent in their current roles as leaders. While I realise there are numerous other areas that may be explored, this is a particular one that struck me.

It quickly became apparent that some of the members had recently been promoted to their current positions and had no previous leadership experience. This meant that behavioural attributes, such as slow rate of decision making, inability to delegate and difficulty in managing underperforming employees came to the fore. While this is not an exhaustive list, these characteristics noticeably impacted our project delivery timeline.

Identifying that stakeholders are new to a leadership role means that ‘typical’ characteristics of newly promoted leaders can be taken into account during project planning. Obviously an understanding of what these characteristics are needs to be obtained first.

Relationship building informs planning, but how much is enough?

It seems somewhat intuitive to perform a certain level of research on stakeholders or team members prior to project engagement. My experience has shown me that doing more homework on stakeholders can help with timeline estimations. In addition, there is considerable value to be gained in building relationships with stakeholders to understand their backgrounds and skill sets.

There are some questions though:

• To what extent can this research be performed?
• How much time do we realistically have to get to know stakeholders before the business demands estimated project timelines?
• Do you believe there is a link between getting to know stakeholders and project planning?

This article originally appeared on Bridging the Gap on 23 May 2011. Click here to view the original article.

The post The link between stakeholder relationships and project planning – Nik Gebhard appeared first on BSG (UK).