The description “Technical Project Manager” has been used carefully and deliberately as staying very close to the technical coalface has always been, and remains, one of the most rewarding aspects of the many and various roles undertaken.
A really good understanding of the technologies is essential to be able to understand the challenges faced by the technical teams. A strong technical ability is also really important in order that innovations can be identified, the development teams can be challenged in a positive way (“We’ve always done it that way”), and to facilitate communications at all the different levels.
The past 36 or so years have provided exposure to a fantastic range of technologies. The learning opportunities presented through this exposure have been challenging, but incredibly satisfying – and, best of all, fun! Of course, there can be no pretence of understanding all these technologies to the finest level of detail. However, it has always been possible to pick up sufficient knowledge to be able to manage developments using them and to support the technical teams. It’s also often possible to transfer techniques or ideas from previous industries into the current situation.
Project Life Cycle
The V-model of the Project Life Cycle is normally applicable in some way, shape or form. It may require customisation to fit a particular style of project, but most of the steps should be relevant, even if they are in a cut-down form. Or, if nothing else, a recognition that this flow should normally be followed does increase the significance of decisions made to skip them! It’s not a complicated concept: Define what is wanted, design and implement it, and check what was created actually matches the original definition.
Project Planning
MS Project is utilised for detailed planning, resource allocations, and cost estimates in a reasonably competent manner and Steelbadger Consulting does have a copy. However, it’s very easy to get sucked into spending more time maintaining “The Plan” than actually getting on with the work, so it’s important that it it remains a servant of, and resource for, the development team, and keeping it up to date does not become a project in its own right!
It is a great tool for generating the overall Gant Chart, identifying the critical paths, and highlighting the inevitable resource conflicts. It’s also the best way to highlight and understand the implications of the inevitable resource and time compromises that have to be made.
Decisions regarding the uses to which it would be put and how much time/effort is to be spent generating and maintaining “The Plan” would be made with the whole team.
Everyone has their own style for plans, and here’s an example of mine.
The Project Triangle – compromises have to be made!
A pet hate is the common misunderstanding by some management that it’s possible to “have your cake and eat it” from a development project perspective. Setting the requirements for a development project defines the desired technical outcomes. At that point there are three main axis to the resulting development process :
1) The time available to complete it (Fast)
2) The desired quality of the finished product (Good)
3) The money to be spent on the development (Cheap)
It’s then possible to pick any two to be dominant for that development process – but the third will “suffer” for the emphasis on the other two.
Fast and good – but NOT cheap
OR
Fast and cheap – but NOT good
OR
Good and cheap – but NOT fast
If it’s fast and cheap…
The output will not be good.
If it’s fast and good…
The development will be not be cheap.
If it’s good and cheap…
The development is unlikely to be delivered fast.