 | PROJECT MANAGEMENT METHODOLOGY | | | | | Does it matter which you use? | Posted by Andrew Spencer on 16/02/2012 |
Last time, I talked about whether project management was a science or an art and touched on methodologies and tools in this context. Most of the comments made in response to the post felt that project management is a mix of science and art, that projects need structure yet they also need good management of people as well as things, good communications and listening and flexibility. I absolutely agree with this and this is true whatever methodology is adopted. By the way the level of comment and response to my last post is very much appreciated ...
 does it matter which project management methodology you use?
This time I am talking about the practical approaches to project management I adopt when managing or directing different types of project, how I adapt methodologies and the tools I use to manage the projects. My approach is quite different depending on the particular project.
Over the years I have had the opportunity to work on a very wide variety of projects that require overt project management, i.e. projects that have a specific role for a project manager(s) and/or a project director. These include the rapid build of a call centre that I talked about last time, incubating a number of businesses from scratch and managing long term software development projects; managing software development of particular systems or products over a period of years. Let's examine a couple in terms of how I and my colleagues tackled them.
In principle I am extremely flexible in how I tackle projects and will both adopt the tools I think best for the project and adapt the methods used as necessary to provide the maximum efficiency and productivity in managing the project. Above all I try to minimise paperwork, whilst recognising that some is absolutely needed to document the project. Today I seek to make documentation electronic and collaborative - more about that below.
Let's look at the rapid build and/or the incubation of a business. They are basically the same; just the time frame may vary and put additional pressures on the project. Fundamentally these projects are ones of short duration, as little as 3 to 4 months through 8 months and consist of office and IT infrastructure delivery, business systems (software and hardware), telecommunications, staff recruitment and website and eCommerce in most cases etc. In the case of many aspects of this list there are design issues including office design, branding, website design, and build issues - all aspects of implementation and delivery.
For this type of project there are quite literally hundreds of tasks but the documentation of requirements from a project point of view is quite limited. For some elements tender or RFP documents are needed, for others outlines of design requirements but no lengthy documentation is needed for those responsible for delivering. What is needed is tight control over timelines for each task, each group of tasks and the project as a whole, keeping a close eye on the critical path and how that changes due to circumstances outside the project's control.
The more visual this process is the better and I have found that MS Project is well up to the task in this type of project. Some of the Gantt charts can be huge - one was 6 feet tall when printed there were so many tasks - but you can see at a glance where you are and where your colleagues are. Obviously you can get quite sophisticated in the handling of resources, progress monitoring and so on but the Gantt is the number one tool. It is also good for keeping stakeholders informed. There was one project which had a very technical build - it was a classic dot.com business - but also some key business drivers that were outside the project proper. By positioning the master print out at the heart of the office area housing both project managers and stakeholders I was able to keep stakeholders informed and re-assured.
In summary the key tool in these projects was MS Project and because of the dynamics of the projects good and honest communication and teamwork between all key members of the project was vital to their success and succeed they did - all, as I recall, on time and on budget and delivering what they were meant to deliver.
In contrast, managing long term software development is very different. There is no closure after a short burst of activity. As soon as one version is out of the door the next is underway. I am going to talk about one software development project environment I was responsible for directing for quite a few years and up to quite recently.
I was responsible for the development and delivery of around 5/6 desktop software projects, more or less in continuous development with a six monthly release cycle, and a number of business systems in the cloud used by upwards of 10,000 long term, regular users, that were on a very roughly 8 week new release cycle. Quite a large team of software development management, developers, test engineers, dedicated PM resource, analyst and technical experts in the field that the software related to, and between 15-20 projects on the go at all times.
In short this was a project management headache. For the business systems a fundamentally agile approach was in use because of the quick release cycles, and for the desktop products a more PRINCE2 approach involving requirement specs, action and decision logs and so on (because of the long gestation period for releases). Consequently project management was fragmented and it was very difficult to understand progress and to track everything that was going on. There was a lot of different documentation in different places.
At the suggestion of the dedicated PM (who spent a lot of time looking at instilling more discipline to the PM processes) we implemented across the whole team an online PM system called AtTask, which is a comprehensive suite of PM tools that cater from the inception of project ideas right through to project closure. So multiple releases of the same product were tracked simultaneously, from generating the ideas to release. The system was best suited to the agile approach but was easily adapted to incorporate things like action and decision logs, risk assessment and other documentation needed to strengthen documentation. Across all projects documentation and approach was standardised.
Most importantly the system gave us control of progress. A project plan expresses what is wanted but with the number of projects on the go and developers working on lots of projects simultaneously it was difficult to track progress. This system required the developers to input hours spent on a task within a project and to express how much progress they had made that day on that task - not the same thing! All of this information was rolled up automatically and we could see at a glance how any project was doing and receive alarms if progress was not good. At the end of a project we also had an excellent set of information of what time was spent on that release and where within it the effort had been expended - helped in planning future releases.
In summary the increases in productivity and knowledge were exceptional and management were given all they needed to effectively manage this complex environment.
So two very different approaches to project management. Hopefully they illustrate the need to adapt, to respond to different environments and not to try and fit a methodology as a size that fits all. I believe in delivering results and I will use the tools and methods needed to achieve success. That is what matters.
Until next time ... 
ANDREW SPENCER
|
 | During Andrew's extensive business career he has worked in a wide cross section of companies, specialising in the creation of contact centres and business systems, software development, telecommunications and project management. Andrew's key skills are:
Business planning and strategy
Matching technology to business needs
Project management
Software development and implementation
Designing and implementing business systems
His work has included sourcing and implementing a new integrated telecoms system for National Energy Services, designing and project managing a new IT and telephony structure for the Greyhound Racing Association, and directing technology development for Wembley plc.
|
|
|
