When I first started as a developer the project manager was usually the team leader who had behind him many years of software development, and was also capable of providing their team the necessary guidance and help when the pressure was on. That was back in the mid to late 90’s where the systems developed required complex coding but the technology set to be used was limited to understanding a front-end, and back-end database language.
From about 2005 onwards things started to change in the workplace – it seemed to me that a new breed of Project Manager (PM) had come onto the market. Whether they existed before or were just ‘new’ to the world of IT is anyone’s guess but based on what I was taught at College, and University before starting work – I think they were probably new to the world of IT. The differences between my early experience of PM’s to the new type can be summarised as follows:-
|Pre 2005 Project Manager Experience||Project Managers from 2005 Onwards|
|Manage team to get the best out of them through discussing requirements scope and setting timescales after talking to the development team.||Developers have to provide the list of tasks and timescales for project manager to put into project plan.|
|Leave the developers to do ‘their’ work with minimum interference.||Constant checking – maybe even twice daily to check project task progress with each developer in team.|
|Help with resourcing issues as and when needed.||Little or no experience of Software Development, so there is no capability to provide guidance or suggest solutions to keep project on track. Most likely solutions take the form of additional ‘resources’ for project – in the form of another developer.|
|Get involved to sort out issues when developers are struggling and report to the business of potential delays/or raise a case for changing scope of project requirements.||Provide constant updates to business stake-holders on project progress to provide necessary ‘comfort’ that work is on track.|
|Mentor younger team members and where possible provide solutions/guidance using their past experience of development.||Very scientific approach to managing the project plan, applying project management principles which can be slightly detached from the working/business environment.|
For many of us developers who experienced this sudden change in project management style – it was a culture shock. It seemed we were working with/for people who were completely ‘cold’ and detached from what we had to accomplish because they did not have the necessary experience to take part in the project like the previous type of management we had become use to. In some cases I have even had the displeasure of working for project managers who did not even have a background in software development – and I always felt that in some complex projects they could never comprehend the size of the task. For this reason most of them are reduced to purely being ‘Status’ checkers and filling in Microsoft Project. The constant ‘status’ checking usually means that developers are losing time because they are having to explain what’s going on to someone who more than likely will NOT understand what the developer is talking about. The result being that this whole process adds unnecessary pressure for the development team as a whole, given that the PM is only interested in meeting the deadline and reporting good news to the business stakeholders.
The Project Plan seems to be the ONLY guiding light for the new PM types to do their work, and the only way they can resolve issues is by requesting additional ‘Developer Resource’ – this allows them to split the already small tasks up even more leading to an incohrent team at times. I remember an incident when a colleague carried out some work on one project which was not a listed task on the plan but it was completed within the overall time-scales but because the task was not on the plan he was constantly questioned by the project manager ‘ but why ? – it’s not on the plan, it’s not on the plan?’ Eventually the developer shouted back with a few expletives with the whole office watching in horror. It turned out that the changes made by the developer earned huge praise from the business users for doing that extra unlisted task, which was of course announced by the head of Development with great pleasure. I am sure many developers have had similar experiences – the following two are highlights from my experience in dealing with the 2005+ generation of PM’s:-
- While working on a data warehouse project I had to write a few Oracle stored procedures, unfortunately the tables and sample data had not been created – that job was assigned to another colleague who was occupied on another project. So I took the matter into my own hands and created the tables and sample data so that I could effectively start coding the stored procedures. When the usual ‘status’ checks were taking place – the PM started to raise their voice down the phone ‘ Why? – Why have you done that? – you were only supposed to do the stored procedures’. I had to kindly explain that to do the stored procedures and check that they compile the underlying tables and some sample data ‘HAD’ to be in place. I still don’t think the PM understood my reasoning.
- On a high-profile web project it was never listed on the original requirements that Exception Handling should be in place. As the project was coming to the end my very experienced web developer colleague raised the issue that we needed to write some Exception Handling. To which the PM replied that it was not in the requirements so why should we do it. Again this was another case of someone doing a job which requires management of tasks for which they do not completely understand or have sufficient experience of.
I recently had coffee with my first proper mentor and project manager and told him of this changing trend since he left for better things. He said – ‘Yes’, they are around like an epidemic and the only way to deal with them is to ‘let them fail’ and manage themselves out of the job. Luckily for me that was the case – the business realised that having such PM’s was too expensive and lacked the communication necessary between Developers and key business users. It turns out that the majority of business users ‘LIKE’ to work directly with developers. I put that down to two main reasons:-
- Developers have knowledge of existing systems and how they work which the users appreciate.
- Developers will have built some understanding of how the business they work for operates and its culture, and therefore will have an insight into how systems can be improved or new systems should be developed.
In the above case the PM’s were replaced by full-time people from the main business who would take on the responsibility of delivering updates to systems by working with the development team, and so far this process has been a huge success.
But there are an underlying set of issues which has led to this new generation of PM that include the following:-
- In the past – there was always that career option of becoming a team lead plus project manager for developers. These days developers (well the ones that I know) – seem to have more options in front of them where they can continue to be technical (such as Web Architect, Solutions Architect etc.) but not have that responsibility of line management and still earn a much higher salary.
- Graduate Programmes run by companies tend to just offer a quick path to project management without gaining sufficient experience in Software Development.
- Despite the pay increase for developers to become project managers – it is now often the case that Developers like to remain developers because they have a genuine interest in the job and cannot see themselves being reduced to checking the status of projects.
- The bastardisation of ‘Transferrable Skills’ where we see project managers from totally different business sectors applying the same project management (from another industry) approach to Software Development projects.
- Of course – the actual methodology being used by a development team can determine the nature of the Project Management style. Agile methods tend to reduce the project management role to status checking.
This does not mean that ALL the new generation of PM’s are bad at their job. No – many of them are effective, and have an enthusiasm for a job that can be described as a very lonely one as it carries a big responsibility that developers sometimes don’t appreciate. They have to make tough decisions – telling the business what they can and cannot have when it comes to system changes or new systems, and also inform them of potential delays or resourcing issues. The things which I believe that the new generation of PM’s excel in are managing the scope of a project which has so often been the downfall of projects in the past.
Let me know your views – even if you are a PM !!!