Give your team room to express themselves
Paul Boag, one of the founders and directors of Headscape, once said; “We specialise in sh*t projects.”
If, like me, you run projects for a normal, every day web agency. If you do not always get the opportunity to be working with the latest cool technology or utilize the next whizz bang idea. If you don’t build sites for rock bands or the latest cool technology start-ups. How do you keep you team excited and enthusiastic about their day jobs? After all, if your team is not interested in the work that they are doing then they will not produce the high standards that you need and that they are capable of. This in turn is demotivating and you end up in a downward spiral.
How do you get your team excited about a project for brown paper bag manufacturers?
Read MoreProject managers: the great ambassadors of our time
A big, if not the biggest, part of my job as a web project manager is dealing with clients. This is actually the part of the job I enjoy the most and see the client as, very much, a part of the project team. I have found that an honest and transparent approach is best when dealing with query’s and problems and involving clients in the general processes of the project (as much as they are able) leads to a smoother road for all concerned.
I have said this before but I see a PM’s role as one of facilitation. I need to enable people to do what they are good at and I need to, wherever possible, stay out of the way. To some extent, this includes client communication.
The ambassador
I recently read a good post by John Reeve; Project Managers: Why every creative agency needs one. In this article he talks about the PM’s role of ambassador. A go-between between the client and the production team. While I agree that this can be necessary at times I see this as only a temporary role.
As PM I need to be aware of all communications. I need to have  a complete overview of the project and understand what is going on when and who needs to do what next. This doesn’t mean that I need to be a middle man. While I still hold on to my technical routes, the chances are, when a client has a question or a problem of a technical nature I will not know the answer.  I will need to go and ask the tech team. Similarly, with a design based question, I generally have no hope without first consulting the design team. So why should I get in way?
Expose your team
We have found it useful to introduce the client to the team at the earliest possible stage in the process. Wherever possible the lead designer and lead tech on a project will be at the project kick-off meeting.  The team will take a lead in conference calls where questions or discussions are to be had about their area of expertise. As long as I am kept in the loop then there is no reason for me as PM act as messenger boy.
When this process works well the client feels more connected with the process and, as they get to know the team, have a greater level of confidence in the the time-scales, quality control and ultimately, the deliverable.
Obviously, some relationships are difficult. This is where the role of “ambassador” goes on for longer than is ideal. As PM it is important to spot and manage these situations so as to still produce the required results and get the job done. I have found this to be a rare scenario.
Openness and transparency as an approach needs to stretch throughout the structure of the project. This includes exposing your team to your clients.
What is your experience?
As a designer or a developer, what is your experience of  dealing directly with a client? As a client, what is your experience of talking directly to production team members or maybe your experience of not being able to? PM’s, do you have experience of this approach going horrible wrong?
Read MoreReduced to stereotypes
I’m often asked questions about the differences between working with designers and developers. Today an article I wrote for boagworld.com was published which takes a brief look at this question.
Donât Reduce Your Designers And Developers To Stereotypes
Read MoreManaging Risk
Risk, in the land of project management, is anything that could potentially get in the way of your project going according to plan and being delivered on time.
There are two types of risk; those that you can do something about, and, yes you guessed it, those that you can’t.
Let me give you some examples from my world as a web project manager at Headscape. Let’s say we have been asked to deliver a project to facilitate a small, but growing, web presence. The client has existing content which needs to be edited and integrated as well as new content that will be supplied by them. The client uses a third party system; previously not used by us but similar to systems we have used before. This third party system needs to be updated by the application we develop.
This is a limited, but not uncommon, project request. So what are the main risks here?
- Content
Content is always a risk. The single biggest reason why a project is delayed at Headscape is content. Clients never, ever, appreciate how long it will take them source, edit, and deliver content.
This is a risk that is completely out of your control. - Third party system
Whenever a third party system is involved (especially one that hasn’t been used before), no matter how similar it is to current systems, you have a risk. There will be a learning curve for your team, documentation will most likely be inadequate, and there is bound to be a new release half way through development that will break everything you have managed to get working.
This risk you can do something about.
Risky Business
Having located the risks what can we do about them?
Highlight them with the client from the very start. If you make the issue of content clear from the beginning, for example, it might, if you are really lucky, mean that the client will take it on board and actually deliver what they need to on time. Failing that it makes it a lot easier for them to swallow if it does end up being the reason a project is delayed.
Talk about potential issues with their third party system. Do not be afraid to present these to the client. My experience has been that, in the main, they appreciate a transparent approach. You can legitimately build in time to the project timeline to allow for the research and learning involved. Even so, there is always an element of the unknown here. If something is going to go wrong with this project, it will involve interfacing with this third party system.
Build in contingency to the budget and the time line. You can not remove the risks but you can plan for them.
It’s easy to fall into the trap hoping that all will go well and you will have project that follows all the best possible scenarios. If you close your eyes, and wish really hard, then you can sell a shorter time line and it might just work out for you. However, if you plan for the risks and build in the required contingency, you might even deliver early.
Clients love to be surprised like that.
As PM’s at Headscape we have started to work together to launch each new project with a project risk assessment. Highlighting all the things that could be a risk to the project running smoothly. Things that are both internal and external to our environment. Things that we can do something about and things that we can’t.
Being aware of these risks and planning for them has had a big impact on our ability successfully set client expectations and deliver projects on time, and on budget.
Read MoreThis week on Boagworld.com
Paul obviously ran out of interesting people to interview this week and so rolled out the perennial plan B. Me.
If you want to listen me talk about the joys of Project Management the checkout the latest boagworld.com podcast.
http://boagworld.com/podcast/158/
Read More