Berwin Leighton Paisner’s IT director describes how technology and the project methodology that usually applies to IT initiatives is driving collaboration between the various roles and functions within the firm.

Some time ago I was asked to speak to a group of professional support lawyers (PSLs) about how know-how could manage the IT input to knowledge management based projects that involved technology. It stopped me in my tracks – how could any project now be owned and managed by a single group? A know-how project is unlikely to exist without a technical element. No enterprise-wide initiative now works without the involvement of a number of different business service teams. Managing complex, multiple-team projects is an art form in itself.

What does this change reflect, and why has it occurred? Firstly, there is the complexity point – changing a service or adding a service is simply more complex in today’s legal business. Factors involved include geographic spread, size, diversity of working practices and styles, languages and time zones. Add those to the fact that even the most straightforward change seems to have a number of interdependencies and it is clear to see the death of the single silo project.

The other clear issue is the pervasive nature of technology. Hardly a business operation or a business team exists without some technology based elements – even the coffee dispenser runs with an internal memory and the ability to blue screen just when you are in desperate need of caffeine. Like every large firm, we are adapting our working practices and project methodologies to conform to this new model and to ensure that everyone involved understands the changes and why these have occurred – and of course starts to work comfortably in the new manner.

I am going to track back across a recent multidisciplinary project to try and draw together the pattern of such exercises.

The anatomy of a seemingly simple project

For some time we have been looking at capturing significant detail in relation to – that holy grail of marketing and the managing partner –referral tracking. Who gives us work, what type of work and what is that work worth? Although, on the back of the automation of the client/matter inception process, we had already been capturing this kind of information, we decided to include a more detailed and robust tracking of referrals. The first stumbling block. The original exercise was the managing partner asking the marketing team for more information.

Marketing then came to the business systems team in IT and, of course, they knew exactly what had to be done – but it certainly involved more than just marketing and technology. It meant intervening on the client and matter inception form, and adding fields of information to be captured. This in turn involved the accounts team, the client compliance unit and the compliance partner. There were five interested parties around the table, and that discounts the technical development group. It was at that point that we realised that this had the potential to become an extremely complex project. We have a fairly welldocumented and tested project methodology in IT, so we started to apply this methodology to this project. If this sounds like change management services being offered by the technology department – read on.

So we started at the normal start point – project definition. Interestingly, we decided that the best definition was to look at the output required and define from that the necessary information for capture. Marketing reviewed and approved the output report design. Then in stepped the international team with further requirements. Now we are six interested parties. New output report format – and then data to be captured and identified followed by another round of projection definition and approval. Now both marketing and the international team felt they should have final sign-off. In stepped the data protection officer. Luckily, he stepped out again reasonably quickly and we remained six active parties involved.

The next phase was much hated by my team and much loved by the finance director. This was to agree the project cost, project milestones and return-on-investment. Agreeing the up-front costs should be relatively easy, but not when you try to cost some recognition of internal time at least into the project phases. Another round of reviews, and we have an agreed definition, cost model and potential return.

Project milestones should be set in accord with the project sponsor – but who was the project sponsor? Marketing could fairly and squarely say they started the request cycle of the technical development team, but the international team could claim to have added significant refinements and therefore say they owned the project. In stepped the seventh member of the team – the managing partner – who changed the output requirements once again. So the project sponsor was? The international team, by a whisker from the marketing team. Then we enter that awful phase; the move from project definition to business process identification and all the pieces that go with building the associated workflows and identifying the data fields. In other words, the backwards-and-forwards phase between the business analysts and the development team. The first concept model was delivered to the review team. It is at this point that some of my colleagues became concerned. They had coped with a project definition document – even a return-oninvestment analysis – but minuted review meetings with action lists, dependencies and milestones were not necessarily a part of their armoury.

A project steering group was formed. This group did not necessarily include those working on the project, but representatives from each of the involved disciplines with a vested interest. Meetings were interesting and for all involved it was something of a learning curve.

Strike one – an obstacle. In the project definition document, I had ensured that a change-control mechanism was introduced. The project had been defined and identified, albeit as a phase-one identification, with all the necessary agreement that phases 2 onwards may well occur. Everyone had agreed. In actual fact, what they had done was say ‘yes’ without realising that means when you say, ‘I want to do this as well,’ you are defining a change that is documented, quantified, itemised, costed and then prioritised.

That came as something of a shock for the more fluffy members of the team. Some of them claimed that this was in their original requirement and it was just that they had not articulated themselves clearly enough. Change control is always a thorny issue and we had agreed that operational fixes would be part of the iterative testing cycle. However, it had to be clear that additional requirements or refined requirements were definitely changes. The fact that we were drawing a line in the sand caused some consternation; but it did guarantee that, from then on, everyone read the documents issued very carefully.

The process, input forms and data reports were all thoroughly tested. Now to show the first final version. ‘Final version’ was a description beyond the finance team, who thought of final as just that, rather than the first demonstration of what might have been a finished product. Back to the change-control document. Armed with an additional set of requirements a release 1.1 seemed to be looming and still no users had seen more than a proof of concept. Back through the iterative cycle of develop, test, correct, test, redevelop, refine and, eventually, the tentative final version – it is amazing how quickly the group adapted – was shown. There was more success this time; the result was much closer to the output required by the sponsors, marketing and the managing partner. Now to the user tests, pilot groups and enterprise roll-out.

User testing was interesting, the project sponsors suddenly finding there was more to the role than just signing off on a proof of concept. Firstly, identifying the test users, then dealing with awareness, supporting training, formal feedback and possible product fixing. This proved a challenging time for all the teams involved as we sought and received user feedback and concerns. From there on it was a comparatively straightforward exercise of piloting and then enterprise-wide roll-out. However, the training presented something of a challenge – even though it took less than ten minutes and was generally done in the working area.

Then the phases that are familiar to everyone in technology: rejection, denial, resistance and ultimate acceptance. The project team found all this quite stressful – I heard one team member ask in a distressed voice ‘why do people not listen?’ And of course, once the first version of the system was rolled out, the subsequent phases and the timetable for their delivery also had to be agreed.

Success evaluation

We did the return-on-investment analysis. Did we get the information we wanted in an organised and usable format and were we gaining a better, more usable understanding of sources of business? The answer was a qualified yes, and as subsequent additional changes occurred, that qualified yes developed into a really useful and usable system with powerful interpretable data.

What was learned?

It was essential that we had a clear mechanism for managing such projects. The formal methodology was necessary because there was a wide range of knowledge and understanding in the project team. This might seem obvious to most but… There were lots of opportunities for team members to blame someone else – preferably not from their working area. We had to apply a rule very quickly that the words ‘they/them’ and ‘us/we’ could not be used. We needed to recognise that we were all part of the same team and we had to accept that if something did not work it was indeed our fault – cabinet responsibility became a watchword.

On the face of it, this was a very simple project. A single output form required from a relatively simple input method. However, there were a lot of different parties involved with somewhat different requirements and this meant that we had to be quite clear about containing those requirements. If we had not, then feature creep would have been absolutely inevitable.

Did we benefit?

Other than achieving the desired result – a relatively comprehensive tracking mechanism for referrals, inwards, internally and externally with party and value identification – there was another very important set of benefits.

• Firstly, all the parties involved learned significant respect for the skill sets held by other members of the project team.
• Secondly, there was an increased understanding of how to work with different groups.
• Finally, a lot of friendships were made, which have made subsequent multidisciplinary business-service projects so much easier and, of course, more fun.

Boundaries fading

Increasingly, as I look at the range of projects run out of the IT team,I start to see that none – with perhaps the exception of the replacement of server hardware or network controllers – are silo projects. I look at our activity on e-billing; accounts. The business managers for the legal teams, the legal team themselves and, of course, technology, are all deeply embroiled. No one section can achieve everything that needs to be done without considerable input from other sections.

I then look at the redevelopment of the intranet. Know-how, PSLs, library and development all work closely together, with communications and HR alongside. Again it is not a single silo project.

Take a project like adding photocopying to network services, so many different individual disciplines are involved. Each of these projects looks at improving internal operations, or creating a more effective manner of getting things done. Internationalism increasingly demands multidisciplinary teams working together on complex projects – here not just disciplines but all sorts of other challenges enter into the equation.

And where next?

So the skill sets start to change and technology often has to take the lead – as much as anything because we probably have more project management skills than most functions. You do need to be much more scrupulous about documenting exactly what is needed. Development needs to follow a robust methodology even if you use agile development techniques.

Every action needs to be agreed and documented with ownership assigned to an individual. Everyone needs to make a much more formal effort to keep others informed. You need to be quite specific about the expectations placed on the non-IT members of the team. Whilst this may sound like familiar territory for technologists, it is quite foreign for people working in other parts of the business to whom structured project methodology represents a new challenge.

And why?

The aim of every firm is to create a challenging but supportive working environment that in turn engenders good clients, great work and, of course, profits.

Each internal or external project has to be set against this background. If the project faces the client then the client has to benefit, but in turn we try to avoid the legal team pedalling too hard for that benefit. If the project faces internal users, then the benefits muat be delivered either in terms of greater efficiency or, perhaps, just happy people.

Approaching projects from an enterprise-wide standpoint creates the opportunity for both of these objectives to be met. The IT team continues to fulfil my mantra. We facilitate – but sometimes it feels like we do a bit more than just that.

Janet Day is Berwin Leighton Paisner’s IT director.