Posts Tagged ‘management’

A Client Management Masterclass

Wednesday, December 2nd, 2009

Today I was given a master class in client management.

I went to meet a client of ours who was not happy with the final quality of the creative output of our work. They had called the meeting as they were thinking of ending the project and cutting their losses.

By the end of the meeting not only were they happy, they had renewed confidence in our abilities and were happy for project to continue. How did this happen? The reason it happened is that I had a secret weapon in the meeting. I was joined by one of my directors at Busara, Pier Bracher who is a master of client management.

I did not say that much in the meeting and watched as Piers led the client through a journey:

Work out if the relationship is still salvageable

If the client does not want to at least try to work things out then is it is a very short meeting, there is no point in talking and the meeting is over. It is then time to send the lawyers in. But on the other hand if they do want to work together that is the first step and this creates some common ground to work on.

Where was the breakdown in the project?

Next you need to find out what the root problem of the relationship breakdown was. This is done by asking lots of questions and really listening to what the client has to say. Try and read between the lines, we were lucky the client was very upfront about the issue; there had been a misunderstanding when it came to the brief and all the issues stemmed from there.

Do not assign blame or dwell on the problems

Now that you know what the issue is, do not assign blame, do not dwell on the problems. It is all about rebuilding trust and convincing the cleint that you can deliver. Trying to assign blame does not help anyone and will only hurt the relationship further. In most situations there is probably fault on both sides but that is not what you need to focus on.

Accept responsibility and create confidence that you can deliver

You need to accept responsibility for the problem and create confidence that you can deliver. Now you know what the problem is you need to work hard to convince the client that you can solve it and exceed their expectations.

Focus on the plan and what is going to happen next

Explain in detail the plan forward, really sell the new plan and give hard deadlines on when things will be done. It is important to fix thing quickly and get back on track. By explaining the plan you are showing evidence that you can deliver. Reiterate where there is agreement and summarise regularly.

Deliver on your promises and over service

The final thing is the most important, you now need to deliver on your promises and over service along the way. If you can do that you have a very good chance of turning a bad situation into a good one.

Quite honestly there were times in the meeting where I had to bite my tongue as the natural thing to do is fight your corner and play the blame game but that does not help anyone.

The key is for you to rebuild confidence in your ability and show conviction that you can deliver on the brief. If you can continue to work together and turn the situation around you can often increase your standing in the client’s mind.

Tags: , ,
Posted in Naked CTO | 2 Comments »

How To Manage Project Changes?

Thursday, April 9th, 2009

Changes to a project can be one of the big issues when managing a project, they can affect your planning, cause confusion and serious delays to projects. Changes made at the beginning of a project usually have less of an impact than when most of the design is complete.

There needs to be a system for people within the team, stakeholders or anyone else to submit changes to the project. This process needs to be documented and everyone should be aware of the steps to take if they have a feature, they feel is essential to the project.

The way changes management is handled usually depends on the size of the project.

Small Project

This is the usual approach, which can work well when you have a small project, and you working in an agile way. However the volume and scope of the changes may mean that the project is delayed and the team become disillusioned. The usual process is:

  • A change comes in from client usually by email
  • Project manager simply updates the project plan
  • The new plan is distributed to the project team

Large Project

Most large projects implement design freeze after the planning process, so all changes have to go through formal change management. This is great as each change is assessed on it merits and whether it materially affects the business case. The downside to this is that better solutions and fast feedback is very difficult to integrate. Formal change management usually follows:

  • Originator of the change fills in a change request form
  • The change request is entered into the change log and issued an id
  • The project manager assess the change for impact and documents their recommendations
  • The project board review the change and make a decision
  • The board’s decision is entered onto the change log
  • If the change was rejected the originator is informed with the decision and reasons
  • If the change is accepted then the project plan is updated
  • Change is implemented, documented and change log updated

A Happy Medium?

Our approach sits in between the two, we do have a formal change management process but it is less formal and only happens after the design phase which is quite collaborative and agile. During the design phase we work with fast iterations with lots of client feedback. Then once the system has been designed, planned and signed off, we have design freeze. If a change is subsequently requested:

  • All changes are placed in a Google doc that everyone can add to
  • Each change is then assessed by someone in the project team and it is placed into:
    • To change
    • Out of scope
    • Phase 2
    • Bug
  • When all the changes for the iteration have been added, we sign off and date the iteration and make the changes in the to change and bugs columns
  • We allow clients to have three rounds of changes/ iterations

The key to the success of any of these methods is making sure that EVERYONE understands the process and that there is someone who enforces the process. It is also very important to get sign off at the key decision points to document that everyone was in agreement.

Tags: , , ,
Posted in Naked CTO | No Comments »

How Much Time Do You Need To Build A Web App?

Monday, March 30th, 2009

I am constantly battling with how do I fit in the time to build my app?

Some people have funding to work on their app full time, but for most of us we do not have the time to build our application during the day as we have other commitments. I have a full time job, a young family, and I am studying for various qualifications so time is very precious.

Recently I have stopped watching TV in the evening, after my son goes to bed, and instead I use the time to build my web app. I work from 8.30pm to 11.00pm or so and I get so much done as there are no emails or phone calls.

I watched a great video from start up school recently that mentioned that Base Camp was built in one year working 9 hours per week. That inspired me a lot so I have decided to devote 10 hours per week after hours to this project at a minimum.

I have also set a very detailed project management plan, with milestones and deadlines. I am treating this like a paid project, it just so happens that I am the main contractor. I started work on this project last Monday and in less than a week I have a working wireframe, with all pages and fields. It is amazing what you can achieve when you have tight deadlines and a small amount of time, it really keeps you focused.

I think everyone has the time to build their own app, the question is how do you organise it and do you make it a priority in your time planning.

Tags: , ,
Posted in Naked Web Apps | No Comments »