Thursday 22 May 2014

Why Projects Succeed


Over the past year I have worked on or managed a number of projects which have been quite successful, they have complete on time, close to, just over or under budged and with happy stakeholders.  Good luck or good project management, here are my thoughts:

Project Management

Defining bad project managers is easy, they are the ones that ask you how their project is going cause they don’t know and/or don’t care, or ask you if they should turn up to their own project meetings. Disengaged, disorganised, no milestones, no updates, no idea of issues and risks, no chance of success. Go too far the other way and you can have a micro managerial fanatic bogged down in detail and making no progress.

A good PM has a firm, but subtle hand on the tiller. They guide the project with informed decisions, communicate clearly and often, build and use relationships to get work done, they delegate, trust, monitor, measure and have contingency plans. They do not seek to offload their responsibilities or hide from the difficult projects. They know how to get things done and who to go to.

Managing Changing Requirements

Unless you are running a very short, very limited scope project, requirements will change. It’s how you manage this change that is important. You can push back and remind the senior user whom signed the high level requirements that they cannot change their minds. Or you can expect changes, the first few demonstrations will also reveal changes to the original requirements and design. As Senior Users begin to use the iteratively built features of your software they will give you feedback which may invalid or ideally fine tune the original requirements. This is great, this is what you want your users to tell you. No point sticking to the original requirements and design if no one wants the end product.

Roles & Responsibilities

I have sat in several meetings and asked “Who is the Project Manager”, only to receive silence or “Who is the Scrum master?”  and even once “Who is the customers/senior user?”. Who is doing what and from that when. This forms the basis of a plan. Otherwise you’re like a group of outfielders running around under a fly ball all yelling “yours”.  Without R&R you cannot have a plan and without a plan, even a high level one, you chances of succeeding are low.

Define whom you and what you need to do, add in a timeframe and bingo, the elements of a good project start coming together.

Communication (previously known as Co-location)

About a year ago I would have sworn that co-location was a key element in a project’s success. But since then I have completed 5 projects working with a company based in another city, doing all the work remotely.  Having clear R&R (as above) and communications is the catalyst to co-location success. Since the person (or persons) is not sitting next to you, you have to put extra effort into communicating in a clear and concise manner. Start with a good plan and work from there, ensuring that everyone knows what they are doing when. Actually I believe that Non-Location maybe better for a project as it prevents you from assuming good communications will come from simply sitting together.

Technical Factors (infrastructure & environments)

This used to be such a headache. I know I have an Applications basis, but how many times has a project been delayed by waiting for infrastructure to be built, configured, ports opened, firewalls changed and soon on. Even in the days of virtual environments and clouds it can still take time. Then there is the time and frustration cost of a failed migration from a System Admin whom cannot follow instructions. Having a good Operations person on the project is invaluable, days of waiting for database and file access turn into minutes and migrations become seamless and hassle free. Frequently – and often without realising it – they become one of the key project resources and unsung hero. I can think of several where I currently work.

Human Factors (context switching & resource planning)

Managing a team of 20+ people includes a strong element resource planning and management. Projects start, stop, pause and take off suddenly. Though a variety of formal and informal communications channels we are made aware of current or planned projects. We plan and resource accordingly. We also had contingency based on project process. The aim of this is to ensure a Developer(s) can stay on a project until completion and avoid distractions. Which leads into context switching. In simple terms it’s an overload of tasks (be it project or incidents) that prevents an individual focusing on completing their work in quality and timely manner. Carefully resource planning and project priorities  will avoid this from happening. The culture of the organisation you work for can assist or hinder this process. I have heard senior managers tell me it’s ok to have a Developer assigned to three active projects – maybe they should learn/remember how to code and try it.

Catalyst & Gelling (Soft Human Factors)

Have you ever notice that there are certain individuals on projects that others will listen to, whom are knowledgeable, willing to support and help others and though not team leaders or managers, others will naturally follow their instruction.  Project teams will naturally bond and gel around these people and their wisdom and knowledge becomes invaluable. I have worked with a few people like this, they are naturally intelligent, calm, patient and helpful. They will also often be very modest and step back from the limelight and move onto the next project. They know who they are, good project managers want them and good people managers retain them.

Conclusion

Go through all the above factors and you come to the conclusion that a successful project is not the result of good luck, but one of good management . Good communication and the skills of an air traffic controller juggling several planes in and outgoing also helps. that it all involves people – whom understand technology  - but not technology itself. I will leave you with my favourite quote of the year so far.

The major problems of our work are not so much technological as sociological in nature. (PeopleWare Productive Projects and Teams (DeMacro & Lister).