Wednesday, January 31, 2007

Proposal Writing Check List

Photo: Noric Dilanchian

Ndarala Group member Dilanchian Lawyers & Consultants (Sydney) continues to set the web standard both for the Group and its members and, more broadly, for all professional services firms.

In this context, I noticed a useful post on the Dilanchian blog on proposal writing that is likely to be of interest to all those who have to write proposals. I like the way that Noric has added a further reading section at the end of the post.

Sunday, January 28, 2007

On Financial Metrics - professional services

Note to Readers: This post first appeared on our Managing the Professional Services Firm blog back on 19 July 2006. We are repeating it here because it provides a simple introduction to some of the key financial metrics relevant to consulting.

In discussions with some of my colleagues on time, time keeping and performance measurement, I found a degree of confusion about some of the terms I used in discussion. For that reason, I thought that it might be helpful to a broader audience if I provided some simple definitions.

Gross Fees

Gross fees simply describes the total value of work we have or will bill the client.


Disbursements are simply the cash-out costs directly involved in doing the job.These may be very small, bus or taxi fares, phone costs. However, in some consulting work they can be very substantial, especially where subcontractors are used.

Net Fees

Net fees, the amount we actually get for the job, equals gross fees minus disbursements. This is our real income.

Work in Progress

Work in progress or WIP represents work done but not yet billed. It includes disbursements where these are to be charged to the client.


The term billings simply describes the value of work actually billed to the client. These billings will include disbursements if these are to be recovered from the client.

Write Ups, Write Downs

Actual billings need not equal WIP. When we come to bill, we may find that we cannot bill the client for all the time involved. In this case, we have to write WIP down. In other cases, we may be able to bill more than the time directly involved. In these cases WIP is written up.

As an aside, write downs are not necessarily bad, write ups not necessarily good. A firm without WIP write downs may be undercharging, a firm with write ups over charging. It depends upon the circumstances.


Clients may pay us in advance for part of the work.In some cases, law is an example, these may be placed in a trust account and excluded from firm accounts until the funds are drawn down upon billing. In consulting, advance payments may be made upon contract start or on meeting certain milestones to help fund the job. In these cases, the prepayment is formally a liability in an accounting sense, diminishing as work is done and WIP created.

Financial Flows

These simply definitions provide the basic financial structure for the standard professional services firm.

As we do the work we create WIP. As our future billings, WIP is a key asset of the firm.WIP minus any write downs plus any write ups then translates into billings as we bill the client. So in balance sheet terms the WIP asset has been replaced by accounts receivable. Then as the client pays, accounts receivable become cash.

Management Issues

All this is pretty simple stuff. However, it does raise some important management issues.

To begin with, the fastest possible translation from WIP creation through to cash receipt is obviously very important and provides a first point of focus. Many firms focus on parts of the process only, usually billings to collection, whereas the whole process needs to be understood.

Secondly, disbursements need to be properly understood and managed especially where these constitute a significant part of gross fees. This is very important for independent consultants leading collective bids.

Thirdly, WIP itself needs to be properly understood and managed. In my view, this is one of the most common areas of failure within professional services.

As a first example, take the standard Government fixed price contract with payments against milestones. Failure to identify and manage WIP in this type of contract quickly leads to over-working at points along the job path, resulting in reduced hourly yields.

As a second example, firms who focus on billings sometimes ignore changes in WIP. They do so at their peril. A billings focus may help get WIP to billings, but this may conceal the fact that the firm's real position is deteriorating because increased billings come from reduced WIP. For that reason, performance statistics need to incorporate both billings and WIP measures.

WIP information is also important for multi-service firms working in different marketplaces.

Even in a single professional field like law, there are considerable variations between customer types and fields of law in areas like pricing, the pattern of WIP creation, write ups, write offs and billings. These need to be understood and accommodated.

Tuesday, January 23, 2007

Contracting Woes 1 - Introduction

This is a short post to introduce a new series of posts.

The relationships between contracting and consulting is a vexed issue for many independent professionals, including many Ndarala members.

The downsizing that has taken place in waves since the seventies has in turn released waves of professionals and managers onto the market, many of who have then looked at contracting as a way of earning income pending acquisition of new jobs, in some cases as a new career option. Because the economics of contracting and consulting are different, these waves of new contractors have had an adverse impact on the consulting marketplace.

More recently, firms have moved to outsourcing and to flexible working arrangements including greater use of contractors. This, or so it is argued, has expanded the contracting marketplace. In fact, this is only partially true.

The importance of contracting to Ndarala members means that there has been a fair bit of analysis in the Group about contracting from the viewpoint of contractor, consultant and customer. We thought that it might be of interest to a broader audience if we reported on some of that analysis.

To make the material more reader friendly, we are going to use this post as a main entry point, progressively adding new posts at the end as they are completed.

We welcome feedback telling us your experiences.

Thursday, January 18, 2007

Project Management for Professionals - Completing the Plan

Note to Reader: this post completes the current series of notes on project management for professionals. A list of previous posts can be found at the end of this post.

We now come to the last stage in the project management cycle, completing the plan.

The first goal in this stage is to obtain client acceptance of the project result. This means that the client agrees that the quality specifications of the project parameters have been met. This part of plan completion overlaps with and is also an integral element of plan implementation.

The second goal is to ensure that we record and gain from the lessons arising from the project.

Given these goals, key steps in plan completion include:

a. Making certain that the client is happy throughout the project with regular feedback

b. Checking each project output before delivery to ensure that it meets specification.

c. Making sure that the client is satisfied with performance at each milestone and with each deliverable. If the client is dissatisfied, then the reasons for this must be clearly established. In this context, it is important to distinguish between:

(i) Client dissatisfaction relating to the original specification, ie, it may not in fact meet the need it was expected to meet. This can arise at any stage in the project. Resolution of this issue may require project modification.

(ii) Client dissatisfaction relating to our performance against specification. In this case we need to be very clear on the grounds of dissatisfaction to ensure that we can take the appropriate corrective action

So long as steps a) through c) have been carried out, final client sign-off should be a formality.

d. Ensuring that we thank everybody who has been involved in the project.

e. Carrying out a full project review to identify and capture lessons.

The process to be followed here is summarised below.


The objectives of the debrief should be to:

1.Identify any deficiencies in performance from our viewpoint or that of the client and suggest ways of overcoming them in future.

2. Identify those features in performance which were particularly good to see what lessons they might hold for our work in general.

3. Identify any other general lessons from the project which might be of broader application to our work, including intellectual property and any spin-offs.

4. Specify resulting action items.

No Fault Debriefs

All debriefs should be carried out on no-fault basis. We should be concerned with deficiencies in our collective work, not those relating to individual performance. Any problems here should in fact have been identified and dealt with.

Debrief Process

Consistent with the debrief objectives, each debrief should among other things:

1. Review performance against budget and time lines.

2. Look at the level of client satisfaction with the result, together with any client suggestions for improvement.

3. Examine project management and production issues to identify any areas where we could have improved performance.

4..Identify any broader issues requiring modifications to policy and procedures.

5. Discuss possible spin-offs.

Prior the debrief the project manager should collect any necessary information and identify any obvious issues for discussion. Following the debrief, the project manager should write up the results, with copies to the project and debriefing files.

Previous Posts in this Series

Note on Copyright

Material in this series is drawn from the Ndarala Group Short Guide to Project Management. The material is copyright Ndarala but may be reproduced and quoted with due acknowledgment.

Wednesday, January 17, 2007

Towards a Discipline of Practice - the Ndarala challenge

We have begun a series of posts on our Managing the Professional Services Firm blog discussing issues associated with the development of a discipline of practice, essentially how we do what we do as professionals.

Our experiences in trying to make our own collective work across disciplines and geographic space are one of the drivers behind the series. For that reason, I thought that I should share some of the Ndarala experience with you.

Ndarala Overview

Ndarala is a funny animal.

We bring together professionals and professional practices from a range of different management related professions - law, a range of management consulting disciplines, training, education, engineering, IT. While most members are in professional practice, we also have members who are employed in management or professional roles in a range of organisations.

Our members are widely spread in geographic terms, creating issues for communication and cooperation. Voluntary participation is central to our operations, meaning that we cannot compel people to do things, to follow particular approaches, in the way a conventional organisation can.

Our professional spread means that we can see at first hand the profound and sometimes subtle differences between professions. Each profession has its its own field of knowledge, its own language, its own culture instilled during early education and training. All these combine to create barriers between and sometimes even within professions even when dealing with common problems.

Multimedia Project Management Example

A simple example to illustrate the point.

Back in 1995 several of us were involved in cooperative activities intended to facilitate the development of a multimedia industry in Australia. This was then an emerging industry spanning sectors and technologies. As part of the industry development side, we decided to organise a seminar on project management since our experience in the IT and communications arena suggested that enhanced skills here were critical to success in an emerging project based sector.

Because multimedia spanned technologies and sectors, we decided that the best format for the seminar was to bring together a number of speakers from different areas to talk about their own experience with project management. So we had speakers from IBM, an independent film production company, an events management company, a consulting company and a law practice.

The seminar was a great success measured by audience response, but it almost failed as it became clear just how different were both the terms and apparent approaches used for what was, after all, a common task, the management of a project. This required us to change track in mid seminar, spending time using multiple white boards to compare and contrast different approaches. As we did so, the similarities became clear. Further, and this was perhaps the greatest benefit from an attendee perspective, our different speakers were drawn into a comparative discussion on approach.

Drawing from this experience, when we came to set up Ndarala the following year (1996) as a network connecting independent management related professionals, we decided to try to build common practice techniques including a focus on project management as a core approach. In doing so, we ran into a series of new problems.

Problems in Inter-professional Cooperation - Profession determines Answer

The first of the new problems was the way in which professional background dictated answers.

Take an HR problem as an example: ask a lawyer and you will get a legal answer; ask an HR professional and you will get an answer set within the bounds of the HR profession; ask a professional manager and you will get a different answer again. Same problem, different solutions.

The extent of this problem was initially unclear to us, simply because it tended to be unimportant for practical day to day purposes. However, it started to become very important when we began looking at cooperative service development and marketing across professional divides.

Take a simple thing like a position statement where some of our legal, HR and management professionals were already providing templates to clients. When we came to look at these, we found that they were as different as chalk and cheese. Part of these differences lay in the differing knowledge domains of the different professionals. But part also drew from the different philosophical biases of the professions themselves.

This is a slippery concept, so let me try to explain. Risk avoidance is important to lawyers. They look for what might go wrong in legal terms, how to prevent this. HR professionals, by contrast, are more concerned with people issues, with control, with ensuring compliance, with firm wide procedures. Management professionals just want to get their job done and are impatient with anything that threatens this. Again, same problem, different answer.

This issue - the impact of different world views among professions - has been discussed at some length on the Managing the Professional Services Firm blog. We found that it affected our attempts to introduce common techniques such as project management by affecting the way those techniques were learned and applied in practice.

Problems in Inter-professional Cooperation - Cooperation is a Skill

We tried to overcome this problem by making more information available and by networking our people from different professions through special interest groups focused on common vertical interests. Here we struck two further linked problems.

Problem one is that we found that inter-disciplinary cooperation is in fact a skill. That is, it can only be learned through practice. We tried to accommodate this through seminars linked to our professional development program with a special focus on case studies. This was reasonably effective, but suffered from the second linked problem, that of time.

Professionals are time poor. This is especially true for independents because they do not have the back-up that can be available in bigger firms. Most time poor professionals simply could not afford the time required to do the type of thing that we were asking of them.

Problems in Inter-Professional Cooperation - a Growing Knowledge Gap

We also found that our difficulties were being accentuated by the growing knowledge gap between those members who were participating in inter-disciplinary cooperation and information exchange - the Group's leading edge - and our less active professionals.

Those who were participating began to develop a new knowledge base and associated language, one that was not shared by our less active professionals, so we had a gap opening up within the Group itself. It took us a while to really realise this, simply because those who were most active communicated more with each other and tended to assume that others also understood.

We are still working this one through.

At a practical level, we simply have to accept the reality of the gap. Again at a practical level, the gap normally does not matter in a day to day sense, since our people can access the newer knowledge as they need it through direct contact with other professionals.

Beyond this, we have been experimenting with different ways of presenting and communicating knowledge to try to make it more accessible. This includes the use of blogs to make material available to both our people and a broader audience.

The Power of Inter-professional Cooperation

In the midst of all this, we have been able to establish the power of inter-professional cooperation. The case study featured on this blog in December on the development of ophthalmic competencies is an example.

Identification of the potential role of competencies in meeting the needs of the Royal Australian (now Australian and New Zealand) College of Ophthalmologists came about because of the combination of our people's management knowledge with work previously done by Ndarala's training professionals in the competency arena. So we have two specialist knowledge domains in combination, one identifying the need, the second the possible solution.

The approach adopted to meeting the need involved the combination of knowledge about competencies to set a framework with the use of facilitation techniques to assist busy specialists to articulate the required information. Again, two knowledge domains.

Dario Tomat, the Group professional providing the facilitation, is an engineer who also has specialist training knowledge. The first was important in both understanding and gaining the trust of the doctors who saw Dario as a fellow professional, the second in structuring and writing up the outcomes.

All this contributed to the success of the project. Then, once completed it was written up as a case study (Group role) and then used as an example to provide a base for further discussion.

Back to a Discipline of Practice

Our work demonstrates both the value of inter-disciplinary work and the problems involved in bringing it about. This experience explains why, as a Group, we are such strong advocates for the development of a discipline of practice, one that can reach back into professional training itself.

Friday, January 12, 2007

Creation and Use of Case Studies

Case studies can be a valuable tool for consolidating and re-presenting experience gained in new ways and to new audiences.

In December we completed a guide to the creation and use of case studies on the managing the professional services firm blog. The relevant posts are:

Thursday, January 11, 2007

Planning and Running an Effective Meeting

It's not always easy running a blog in the midst of day-to-day pressures. Here I was pleased that Ndarala professional David Jago has resumed posting on his Smart Meetings blog.

David often has very thoughtful comments on ways to improve meeting performance as well as on various facilitative techniques.

Thursday, January 04, 2007

Project Management for Professionals - Implementing the Plan

Ten guidelines for effective negotiation:

  1. Be prepared - know what outcome you want and
  2. Minimise perceptual differences - ask questions to gain
  3. Listen - questions are no good unless you listen to the
  4. Take notes - what has been agreed and what remains to be
  5. Be creative - look for new solutions.
  6. Help the other party
  7. Make trade-offs - trade what is cheap to you but
    valuable to the other party for what is valuable to you but cheap to the other
  8. Be quick to apologise
  9. Avoid ultimatums
  10. Set realistic deadlines.

If you have followed the earlier steps, you should now have a well structured project plan along with the core team necessary to carry the plan out. We now move to implementation.

Key steps in implementing the Plan include:

a. maintaining clear project responsibilities.

The designated project manager is responsible for the overall project and must agree with any changes that affect project deliverables or costs. Similarly, those responsible for specific tasks are responsible for delivery of the tasks and must be made aware of any changes. Failure to maintain clear project responsibilities is a significant cause of project failure.

b. effective performance monitoring.

You need to know how the project is going in terms of quality, cost and time, so you need proper internal information flows and regular progress reports. These will vary from project to project but may include various reviews of progress against plan, review of problems encountered and the way they were handled, reviews of anticipated problems and of ways of handling them.

c. negotiating for material, supplies and services.

The importance of this one depends very much on the project itself. The three key variables are quality, cost and timeliness.

d. Problem resolution

In larger projects, a variety of difficulties may arise. Common strategies for resolving differences are:

  • Demanding
  • Problem Solving
  • Bargaining
  • Giving In

Each strategy has its place. Learning to distinguish among the various types of situations and adopting an approach that has the greatest chance of success in the long run is more effective overall.

No matter how good the project plan, problems will arise in implementation that will need to be sorted out. Common problems include:

i) Estimating errors. Any project plan includes assumptions, best estimates, in regard to time inputs, elapsed time, quantity and cost of other inputs. These need to be identified and resolved.

ii) Mispecification of relationships. All projects involve modules, sets of related tasks, linking with other modules in a variety of ways. These relationships have to be specified in advance and may prove to be in error. Again, it is important that any errors are identified as early as possible to allow maximum time for corrective action.

iii) Technical and commercial risk. Projects may involve significant technical or commercial risks. The more obvious ones are (should be) identified in the project plan. However, new ones may emerge as the project proceeds.

iv) Stakeholder conflict. Many projects involve a mix of sometimes competing interests. Even if these have been properly identified during the project definition and project planning stages, their resolution may not be easy.

d. ensuring that the client is kept fully informed.

Most projects involve a client. This holds even for internal projects. Reporting lines and processes need to be clearly specified.

Previous Posts in this Series

Note on Copyright

Material in this series is drawn from the Ndarala Group Short Guide to Project Management. The material is copyright Ndarala but may be reproduced and quoted with due acknowledgment.

Tuesday, January 02, 2007

Welcome to the New Year

Photo: Gordon Smith, Copperhead. Copperheads are shy and retiring by nature, and prefer to escape rather than fight where escape is possible, and their venom is, by Australian standards, only moderately toxic (equal on a per-mg basis to that of the Indian Cobra!). Nevertheless, they deliver a substantial quantity of venom and a copperhead bite left untreated can easily kill a healthy adult human.

Welcome to the new year.

Why a copperhead illustration? Well, partly because it is a good photo. But also because the copperhead provides a management lesson.

The copperhead is a shy snake. You have to provoke it before it bites, but if provoked it can kill you. In this sense, it is like many organisations. Mismanage them enough, prod them enough, and they will bite back. That is why so many new brooms fail.