First of all, what is Project management?
Project management is the discipline of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals for a client within a specific time-frame.
Some key responsibilities for project managers include planning, managing risks, managing scope change, managing budget and managing resources.
As a project manager in a busy agency, every day is different, and every project requires a specific approach. Sometimes this can be difficult, as projects often run in a concurrent fashion as opposed to a linear one. This means that we are often working on multiple projects at a time. A big challenge for me is resources. Ours is a busy studio so lots of project resources, such as designers or developers can often be booked onto other projects.
Another challenge is ensuring that there is no scope creep. Scope creep is something that lies outside the scope of the project, it’s a change to what we said we would deliver. Scope creep can be introduced by the client or by us. Sometimes our own team might introduce scope creep because they get an idea for something amazing. Where we run into trouble is when a webpage that started out with five elements, suddenly has seven elements on it. The team may think that these look much better and that the page needs them,but unfortunately, we have only budgeted for five. Part of my job is to manage that to ensure that projects are delivered within the budget.
To give each the attention needed, a highly organised studio-wide schedule is implemented in order to make sure that each project ticks over and hits all of its targets. Throughout the process of project management, it is crucial that we constantly evaluate ourselves, our objectives, and our processes. As a project manager, it is central to my role to measure the success of my projects.
No project is perfect but what makes a project successful?
I’ll start with the obvious:
The project team provide the estimates based on the scope we know at the time and this forms the basis of the quotes we work with. It’s crucial that the project team are involved in preparing the quotes; otherwise it won’t be accurate and immediately would be a risk.
I’m a great believer in setting a realistic project plan; one that is achievable and based around the estimates that the project team have provided. After one too many projects, I started to understand the process more and more and know where in the project appropriate time needs to be allowed; and where in some cases time can be clawed back.
This is when the agreed Business Requirements Document (BRD) becomes my best friend as it helps me ensure that what we are delivering is within scope and that the client is getting what they asked for.
There are however other factors that make a a project successful...
Is my client happy with how the project went and the end result? Does it meet their requirements?
Project team satisfaction
Are the project team satisfied with what they delivered and the way it was delivered?
How do you know what lessons to take away from a project?
Success comes in all shapes and sizes, and I need to understand where my projects have succeeded; and where they perhaps didn’t. Where they haven’t succeeded, it is important that I recognise why so that I can bring any lessons learned with me to my next project.
At the end of every project we have a ‘lesson learned’ session, where the whole project team sits down and reviews what they think went well and what they think didn’t go well. Over the last few of these sessions, two significant lessons have emerged which are now embedded in our practices:
In some cases, we have decided not to have a functional specification as part of a project; as they take up a lot of time. For some it is definitely needed and for some it is not needed. We found that it is worth spending a little time at the start of each project figuring out whether this is needed, as it can save a lot of time down the line.
The lesson learned about wireframes is that they are crucial: always start with wireframes before designs. Previously, on projects with a tight time frame, we decided to jump straight into design. This is a huge risk and we have learned that this is not always the way to approach it.
For me, knowing I have learnt from a project and gained experience is always a good thing. If the project isn’t a success, it’s important to evaluate the reasons why so that for the next project, these things can be taken into consideration.