Beyond the alphabet soup of PRINCE2, MSP, PMBOK, ITIL, Agile
I was reflecting on the news during the week that a second head has rolled in the Novopay debacle. After Education Secretary Lesley Longstone, Deputy Secretary Anne Jackson has also fallen on her sword. There has been some interesting commentary regarding the extent government should be involved in IT.
Government policy changes as often as election cycles, sometimes even more frequently with change of ministers. It seems quite a common consensus around the developed world that government is gradually stepping away from providing the IT services and replacing with suppliers. I have worked most of my career in the supplier space. Still I wonder if sometimes it provides the best outcome for the governments. There are good reasons to outsource to experts. Are there equally good reasons not to?
In my experience, those of us working in IT have an inflated sense of self worth. We tend to forget that IT is almost without exception an enabler of capability. No one does IT because they need to deliver IT. It is therefore a support activity to help core deliverables of an organisation. It is argued that this activity should be outsourced to experts to deliver. Expertise in IT does not equal expertise in delivering the business outcomes for the organisation. This distinction is not always made.
Quality in any IT service delivery is relative to the the context. You can provide a quality service only when you build up knowledge of the outcomes the organisation is trying to deliver. A good understanding of the constraints are also needed for success. These are constantly evolving. In a usual scenario a number of suppliers will provide a range of services to an organisation. Typically none will have visibility of the end outcomes desired. There are so many instances of projects delivered to specifications that do not deliver business benefits, it is frightening.
The pressure from bean counters to reduce head count has resulted in false accounting. People are very resourceful and learn to manipulate systems to get what they need. By reducing IT head count, the cost is passed on to specific projects. When suppliers are engaged in those projects, government is paying for the actual cost to deliver the project + contingency applied by the supplier + supplier’s profit margin. Even if you retain the same vendor, you are not always guaranteed retention of intellectual property. In reality the cost to deliver the same outcome is no less, and is likely to be significantly more.
I do not see government contracting model encouraging sharing of risks and rewards. Contracting method encourages offloading risks totally to the other party. This results in most contracts being administered in an adversarial way. Where deliverables are provided for a fixed cost, suppliers will always try and deliver minimum that will pass acceptance, rather than trying to maximise outcomes. Where many individual contractors are used, I have seen instances where they have tried to stretch out the delivery in subtle ways.
The role of the government is to deliver a service to the taxpayers. All that is required to deliver the service in an effective and efficient manner should be part of the role of government. A government department has its own legal teams and human resource staff. Why should IT be any different. This is even more critical considering the long list of failed IT projects. Disagree? Let’s discuss.
No Estimates is a concept that I had not come across until very recently. The basic premise of No Estimates is there is significant inaccuracy in software development estimates. Even when you spend a lot of time estimating, it is still not necessarily accurate enough to give you an exact picture. Therefore, the time spent estimating does not give you a reward for that effort. Proponents of No Estimates argue you may as well spend that time and effort into understanding what the most important feature is to the user and concentrate on getting that delivered well. Once delivered, you concentrate on the next most import feature and so on.
When I first read about it, my initial reaction was it was like throwing the baby out with the bath water. Just because we are not as accurate at estimating simply giving it up seemed like lunacy. On reflection however, I can see it being useful for in-house teams that are supporting a business application. There the organisation has already seen value in continuous improvement and has accepted the software developers as part of the package to deliver the business outcome. You can concentrate on small measurable improvements to the application as directed by business. The users in this case are well versed with the application and are able to explain the desired improvement. Interestingly enough, in my experience this type of development is comparatively easier to estimate than others.
I also had a thought that product development teams may be able to use this in some manner. The rationale was they have quite a bit of control in terms of what they can cut out of scope if something turns out to be more difficult than initially perceived. However, the tradeoffs they make are not necessarily linear. There is usually not comparison that you can unilaterally say is feature A versus feature B. Feature A may very well be more important, only if it is likely to be no more than 20% more in cost. No Estimates as a concept is not well geared to help in this scenario.
Even in scenarios where No Estimate is a reasonable course, I see significant risk of what I call ‘design blinkers’ – only taking into account the immediate requirement(s), rather than an overall view to limit rework. Design blinkers happen in all form of software development. This is because you can only design for your known scope. By limiting your thinking horizon to the next most important feature, you are in effect likely to encourage less holistic design.
From the reading I’ve done so far, it appears there is a level of misunderstanding in what estimates are used for in projects. There are no perfect estimates – projects are by nature risky. You can only ever be expected to deliver estimates with complete accuracy early on. They should get progressively accurate as you go through the various phases of the project. Initial estimates to judge whether the client has the cost appetiate to even embark on the journey, then further refining to understand whether your organisation can execute the project safely with a level of profit. These estimates will be less accurate than your feature level estimates, that you will be building up when the project goes into execution. In most cases you use multiple methods of estimating than simply a combination of all the features – previous track record, comparative scale with other similar projects and some level of feature based estimation.
In my view there will be very few situations where you can get away with doing no estimates and be able to make the decisions you or your customer needs to make. The answer is not to avoid estimating, but estimate at the level of accuracy that is required to make the decisions. Never estimate $X or hours Y. Always clearly state estimates with their level of accuracy i.e., $A to B or hours Y to Z.
Image Credit: Dilbert (Scott Adams)
I attended a training seminar the other day on finance and accounting for non financial managers. It was an interesting training course. If you consider the constraints within which project managers must work to, one is financial. The last time I studied anything remotely close was accounting 101 during the first year of my under graduate degree some 17 years ago.
The course was run by Victoria University Professional and Executive Development school. Not being a student of accounting and finance, the seminar title seemed like exactly something that I’d be able to use in my project management role. As the course outline was being set out, I realised this was probably the wrong form of accounting for me. The primary focus was on accounting concepts and how to understand company accounts and performance. It appears management accounting is what I should’ve been looking into for making decisions based on numbers.
While I didn’t totally achieve what I wanted to in terms of outcome, it wasn’t a total waste of time either. We focused on importance of cash and return on investment based on various capitalisation models. I had never thought to consider projects, or even business cases along those lines. It is a very useful knowledge to have when considering the straight ROI figures. I will be much wiser to attempts at manipulation along those lines.
This all made me think, how much financial knowledge o you really need to manage projects effectively? Projects are usually incurring expense until such time it is transitioned into the business. Usually project managers will not be responsible for the realisation of he benefits. That means unlike accounting, all the numbers are in one direction. That is why most project managers will be able to get away with limited or no accounting and finance knowledge, as long as te are reasonably good with numbers.
This all changes when the project manger becomes responsible for both generating income and controlling expenses, which is the case in supplier environments. I have a set number of resources that I can utilise for various projects. How I use these resources not only determines success, but also income for my team. In strict sense this is more akin to portfolio management, rather than project management. In this scenario, I found the focus on importance of cashflow and various funding models was very useful.
If you are running a programme that is designed to deliver a financial benefit, I can see a very practical application in terms of analysing if you’re meeting the desired profit targets. Similarly, if your benefits can be quantified in terms of monetary value, then understanding accounting and finance is very useful. However, in general I haven’t found the lack of understanding in this area hasn’t necessarily made life any more difficult, as I am comfortable with numbers in general.
My role involves more than simply managing projects. It also includes forecasting of revenues, participating in the sales process and contributing to strategy among others. I still think understanding management accounting may be very useful. I will probably look to get some more professional development in that area. Again, those in my view are more portfolio management in nature, rather than project management.
What has your experience been? Am I totally off track?
Image Credit: best-financemanager.com
Anyone spending a decent amount of time in project management field will sometimes have projects from time to time that experience significant difficulties. For all the planning, it is never possible to predict all the eventualities and therefore foreseeing all risks. Projects are by nature more risky than other business activities. It is always useful to apply a few techniques to aid in such situations.
1. Show leadership
An oft repeated cliché this is something that is hard to explain in terms of action. When things go wrong there is plenty of nerves in the project team and management. Project team members often struggle to think beyond their immediate problem. You will find internal executives or sponsors worrying about contractual obligations and any fallout with the customer. Showing leadership in this context is to ensure this uncertainty does not spread into panic. The role of the project manager is to steer a clear course and stopping any blame game that may raise its ugly head. Now is not the time for that. Focus on why after the project.
2. Avoid temptation to simply throw more resource
A common reaction to a struggling project is to throw more resources at it. If the project is of high visibility and management is not able to provide subject matter expertise, they will feel they need to contribute somehow to correct it. The commodity at their disposal is resources. Be wary of this. More cooks do not equate to a better dish. You may need to enlist some mentoring for project team members or even yourself if you are managing a project outside of your technical expertise. Always consider how much time it will take before new resources can contribute to the project. If the issue is time, you will virtually ensure a delayed delivery by adding resources. Also take into account the additional communication required to successfully integrate them.
3. Avoid sugar coating
There is a temptation to play things down as things start going wrong to avoid creating panic. I have found it easier to be transparent about progress. Late surprises will compromise integrity of the project like no other. While your stakeholders likely be upset with you, in the long run it will get you more respect. You need to be clear with communication internally. If you need some of your resources to be allowed uninterrupted project time, you need to give that clear sense of urgency. Otherwise, you will not get the outcome you desire. Clear does not mean antagonising your people. You may need the same people later in the project or for a subsequent project. Do not burn bridges.
4. Undertake review
Very often when a troublesome project is completed, people are so pleased to see the back of it, no learning takes place. This is just about the worst thing you can do. You are not making sure same problems are not repeated. Wait for a reasonable period after project closure to undertake review. While things are still raw, people are more likely to be defensive and the value you get from the exercise will be limited. When you review, structure it so everyone has the ability to come forward with what they could have done better. Start yourself to show the way. If people are forthcoming, leave it at that. Your aim should be to avoid repeat, not to be punitive.
5. Follow up
Do not leave the review in a document and expect the next project to pick up on it. Use the information from your review to recommend training plans and process changes for the organisation. Present these to someone with influence within the organisation. After some time follow up on progress of the recommendations. Improvement takes hard work and tenacity.
Do you have any rules for managing troubled projects? I’d be very keen to hear.
The three main techniques for rapid prototyping are: storyboarding, paper prototyping, digital prototypes.
Senior Project Manager at Eagle Technology, APMG Accredited ITIL, MSP + PRINCE2 Practitioner, governance expert, cricket fanatic, squash pretender. Opinions expressed are purely from my experience of leading teams and running projects, and in no way claims to represent those of my employers or customers.
