It may sound obvious to most but Project Management and Line Management are different roles and each brings specific skills, working together in an effective organisation.
Line managers have the ongoing responsibility for the admin, personal development, job satisfaction and well-being of those under their charge.
Project Managers focus is on achieving the objectives of a project. He/she has responsibilities the Line Manager may not (such as managing Risk, Scope, and the Customer).
The temporary nature of projects means that good quality line management is vital to ensure staff have the continuity and stability from which to contribute effectively to their projects. A company run by Project Managers would be a pretty scary place.
Like understanding your customer, the more you know your sponsor the easier it will be to have effective communications with them.
Work out how much information they require and if necessary have a conversation openly on when they want you to advise them, what they need in reports, how often, etc.
I would always push to lower the threshold a tad, as it’s better to have raised an issue that gets quickly resolved, than hold-back on a critical problem. After all the Sponsor is the ultimate stakeholder and should have the greatest to gain/lose from the outcome of the project.
Understand where you are going before you leave.
Sounds simple enough. And yet despite all the theory and experience of decades of software development, it’s amazing how often projects are pursued in a ‘pioneering’ fashion.
An impatience to start build can be overwhelming, but projects routinely fail because insufficient thought and preparation is done before cutting code.
For the project team to work effectively, developers need to know where their work fits into the whole and also what business needs they are aiming to satisfy.
A failure to adequately comprehend and define how the solution will acheive the business objectives and ‘realise the benefits’ is a big risk and can easily mean the project will be late, blow the budget and leave an unhappy customer in it’s wake.
In terms of Project Control Processes, I’ve come to consider Risks and Issues as intrinsically linked, despite that many sources and courses teach these seperately.
Here’s the logic: An Issue is a Risk with a 100% likelyhood.
Issues are problems that need to be managed, in the same way as a risk once a trigger point has been reached.
The procedures for distinct risk registers and issue logs, means that Project managers can at best incur greater administration or at worst they can lose the holistic view that a combined view would give.
Ask yourself how many status meetings have you been to where the majority of the session is spent fire-fighting the issues and zipping through the risk log right at the end – or worst still, suggesting that be looked-at at the next meeting.
If the scoring system were adequately calculated it could be that some HUGE risks should merit higher attention than minor issues and should in truth be prioritised higher up any single list.
A browse of the shelves of a good bookstore and you’ll find quite a few books pronouncing the principles of project management. However, the literary style of many are given in the “Project Management made easy” mode.
Books which give the impression that Project Management need not be a constraint to the development process are misleading. Structure and control will always place constraints on what could be done in the fastest possible time. What the authors are trying to convey is that these constraints can be minimised, not that they can be jettisoned.
I strongly reccomend a site I found recently (http://www.projectsmart.co.uk/) which covers a good range of sensible material, and beats browsing “Project Management for dummies” or “The Ten-Minute Project Manager”-type media in your local bookshop.