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

At the outset of every engagement, we spend time architecting the project to ensure that there is alignment between the organisation’s strategy, the proposed deliverable of the project and the approach to be adopted. Over the years, we’ve seen many, uhm, less than optimal practices across the industry. We decided to write them up in a “cheat sheet” for project architects.

Project architecting for anti-progress

Make roles and responsibilities unclear. In fact, why even consider them at all? Just assign people to the project and hope that they will get on with it. This way, the real “diamonds in the rough” will get a chance to shine. It’s Darwinism, project style.

Make your documentation as long as possible. Long documents are proof that you’ve consulted widely and thought hard. Stakeholders really appreciate them because they get a chance to be sure that every single conceivable exception, no matter how unlikely, has been considered. They also look really impressive on the desk. Aim for at least 250 pages (excluding models, these should be in a separate appendix).

Ensure that there are dozens of people engaged in review cycles. Surely it is better to get insight from everybody in the organisation? And customers. Not to mention suppliers and regulators. If you research and review requirements with a massive stakeholder group then you’re sure to be able to deliver a fantastically thick requirements document.

Everyone needs to agree on everything before progressing any single decision. This is a project, not an autocratic government. It needs to be setup so that every decision is consensus driven across a wide stakeholder group. Especially the little decisions, those are most important. Documenting the never-ending email chains as decisions progress provides great content for your appendices.

Encourage teams to operate as functional silos during delivery. Talking to each other only slows things down and gives people the illusion of being involved. It’s much better to ensure that different parts of the project team are minutely focused on their own work at the expense of anything else. This will allow you to write documentation much more quickly.

Waterfall. Only. Forever. Thinking through different delivery approaches will only slow down the project. Why waste time planning how to do something when you could be having meetings and writing documents? Those new fangled approaches are only a fad anyway, everyone knows the space programme / banking platform / other important thing was built using a waterfall approach.

Keep it big. Breaking up the scope into small manageable chunks only demonstrates an inability to be a big picture thinker. Also, you never know whether you’ll get budget again so be sure to use it all in design and delivery. With all the analysis you’re doing, it’s almost certain that your design will be totally accurate.

Make change within the project complex. Don’t let stakeholders fool you with changes to business priority and process. The point of the waterfall approach is to draw a line in the sand. There’s no point in a line if you don’t police it. Make it exceptionally difficult to cross that line. This will demonstrate how serious you are about meeting the project ambitions and win you respect across your stakeholder community.

Paper, paper and more paper. Don’t be fooled by tools that allow either better management of requirements throughout the project or collaborative working environments. These too are a fad. There are many detailed spreadsheet templates that will allow you to track traceability across a complex design making for value-adding work on the project team. Paper will never go out of fashion.

Make workshops cover as much ground as possible. Your stakeholders are busy. And they need some time to be available to review your thoroughly written documents. Be sure to make workshops cover every angle – the more you can cram into a single whiteboard session, the better. Don’t worry about focusing on the details, stakeholders often get this type of stuff confused anyway. It’s your job to address this as you write out an activity diagram, use case and associated notation for every single process.

Measuring benefits is like counting up your old Italian Lira. Benefits only begin accruing after the project is complete. By then, you should be focused on some other important project or change. You want to be a forward thinker, not stuck in the past.

Do you have any more rules to architect projects for anti-progress? Let us know in the comments.

The post Project architecting for anti-progress appeared first on BSG (UK).