Beyond the alphabet soup of PRINCE2, MSP, PMBOK, ITIL, Agile
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.
I have taken a bit of time mulling over this post. I was born in Bangladesh, but have been an expat for most of my life. As I looked on in horror at the calamitous scenes from the garment factory collapse in Savar and the outpouring of grief from various quarters, I could not help but think if the likes of Walt Disney, Diesel, GAP and Walmart are in some ways not partly responsible for it. What of my own profession where I have managed projects where I have been both the supplier and customer in outsourcing situations … how much effort did I really put in to ascertain conditions?
Let us look at the motivations of outsourcing. There are usually one of two reasons to outsource. First an almost without fail the reason is cheaper supply cost. A secondary reason I have sometimes dealt with is rapid mobilisation, which in New Zealand context is difficult to do simply because of the size of the market. It is probably unfair to even try and compare projects I delivered as the sub-contractor, as the working conditions here are in no way comparable to the scenario in Savar. However, I did utilise sub-contractors in India for some projects. Did I really try and explore if conditions are great there? How are they able to mobilise so quickly. What happens after the project is complete? Not really, I just assumed that someone in the executive had done that due diligence. Never occurred to me to check.
Can this lax attitude be excused? Companies spend a lot of time selecting suppliers with the correct skill set, that can deliver on time, have the correct quality control measures. Should they not be expected to provide equal oversight to the working conditions? This becomes quite a thorny issue. They are engaging the supplier for a set of services or products. They can legitimately expect working conditions should be responsibility of local administration. Many of these suppliers serve many masters. Who should then be responsible for conditions.
Even if these companies are willing to take on the burden of ensuring good working conditions, can they really achieve that? The building that collapsed housed five garment factories and had an A category safety certificate from the Fire Service, even though the entire construction has been documented to be illegal. Local officials have obviously been on the take for some time to allow the construction and then issuing of false safety certificates. No reasonable person can lay the blame on the outsourcing companies for such failures.
Pope Francis called the working conditions as modern slave labour. There is an element of truth in there. However, one must be careful not to judge conditions through western standards only. $38 buys a lot more in Bangladesh than it does anywhere else. This industry also employs 4 million workers, same as the entire population of New Zealand, 80% of them female. It has given a large section of the community a voice and self reliance that never existed before. Those protesting in front of these companies to stop doing business in Bangladesh must remember that would hurt these people more than the owners.
The world runs on influence. What these companies have over many of the suppliers is leverage. They use this every day to drive down their procurement costs. They should use the same to better the working conditions. As these companies have found out, there is a reputation risk even if there is no legal obligations. Treat the working conditions in the supplier environment as a risk that needs to be managed like any.
Where there is a will, there is a way. The world came together to end trade of conflict diamonds and apartheid in South Africa. Surely some social responsibility is not too much to ask.
Image Credit: http://www.sifascorner.com
As I was writing my last post on Novopay, I was also contemplating how one can rescue such a project. The minister in charge, Stephen Joyce has announced a $5M fund for addressing the issues. How would this work in real life? Reports are rife that the government wanted to get its money back from Talent2. That, along with the fact that relationships are already at breaking point, are not good success factors for the project. So what are some of the things that need to happen before you can achieve any improvement?
When doctors treat patients with substance abuse, the first thing they try to instil on patients is the acknowledgement that a problem exists. The environment around failed IT projects is exactly the same. It lurches from one problem to another while trying to apply band aids to keep things going. Until parties are willing to admit problems exist, there is no hope for a resolution. If you keep doing the same things there is no chance of the result being any different than what it is today. It is very likely that some within the project saw the train wreck coming and may have voiced it. Seek those out to understand what went wrong.
One of the basic practices of IT is that software developers do not test their own code. It is not because they are not capable. In fact, they should be more capable than anyone else. However, as human beings we are predisposed to not finding holes in our creation. Same is true for the management of the project. The current status is a reflection of many decisions taken through the course of it. Many in the management will feel the decisions were correct at the time with the information they had at hand. You need to remove the management decision makers from both the supplier and customer to ensure progress. Leaving them intact will risk required changes not happening. If the changes do happen, it risks those people losing their authority as they have been “proven” wrong in hindsight. To top manager from the public service, Education Secretary Lesley Longstone has already resigned. If the same has not happened from the supplier Talent2, that needs to happen.
In a major failure it may sound couter intuitive to look for small wins, as the problem is a sizeable one. Most adults are reasonably sensible and not easily taken in by bulls**t. They are well aware that a major failure like Novopay is not going to be resolved quickly. What you need to achieve at all costs is some confidence among your user base that improvements are underway and they can see a light at the end of the tunnel. Bigger your ambition is, more balls are in the air and higher the chance of it all coming crashing down because of weak foundations. Identify how you are looking to improve, set target of small improvements often and communicate honestly.
As Fred Brooks Jr has pointed out, the most reliable software is written by one or two man bands. The need for quicker output requires many more developers and as a result introduces complexities several folds. One of the major reasons projects fail is because communication is poor. Having large teams working on it is therefore more risky than the original projects. It is a common tendency in projects to throw more resources at a problem. That is just about the worst things you can do in a failed project. With smaller wins go for smaller teams.
For all the best will in the world sometimes you will not be able to retrieve failed projects. Cost of retrieval may be higher than doing another project from scratch. It also may not give you the benefits you were after based on the additional cost. You may find there is more political will to spend in trying to fix something than re-doing it correctly or abandoning it. Be careful to be seduced by that. It is difficult to contemplate ditching a system like Novopay as that cannot be done without a replacement to pay the teachers. Supermarket chains, farms and IT industry contains a lot of similar requirements with a considerable part time contract staff alongside permanent staff with various levels of skills and entitlements. A fully functional system that does 90% of the requirements may be better than an error prone system designed to deliver all of the requirements.
Have you worked on recovery of a failed project? I will be interested to hear your feedback on Novopay or even failed projects in general.
After nearly a two month hiatus in blog posts, it is time to jump back on the horse. In that time, I have spent five weeks on vacation and either side of it two and a bit weeks in doing handover and picking the work back again. I thought it would be useful to share lessons I learned from this exercise.
The Preparation
This is the most stressful part of going on a long vacation. I had worried about projects suffering in my absence due to lack of control or guidance. Clarity in decision making based on experience is a key skill of a Project Manager. As many Project Managers do, I still carry my cell phone during short holidays. There is always a fallback if the wheels start to wobble. On such a prolonged vacation overseas I was not about to entertain being on call. I therefore asked for a short term stand-in for my role. I involved in various projects during a two week period to ensure he had sufficient background in the processes we followed and status of the projects to carry them through for five weeks.
The Vacation
This was the first vacation of this length I had taken in nearly five years. Having done the legwork with my stand-in, I was surprisingly relaxed during the holiday. I cannot put my hand on heart and say I never worried. Anyone with a level of responsibility will from time to time worry about events beyond their control that they cannot steer their team through. Most of the incumbent project teams and support teams – sales and management – were still there. Needless to say I enjoyed my time off in the knowledge that with the handover I gave and the available support structure the risk of total cock-up was relatively low.
After the Vacation
On my return I was pleased to see three quarters of the activities were done as I had wanted. Some were left for my return that required a level of experience or authority to carry out. While there were some thing done slightly differently, I can accept that as best effort choices based on information at hand. One particular area was done better than I had expected – breaking development work packages into short sprints. The week following the vacation was spent trying to get back to the rhythm of work and getting a handover.
What the team learned
The team understood the consideration, communication and time it takes to make decisions on project related matters. Many a time some of these challenges are nto visible to the project team (or for management for that matter) and cannot be readily appreciated. The fact that quite a few decisions were deferred and a lot of the decisions required quite a bit of internal discussion gave them an appreciation of challenges I deal with on a daily manner.
What I learned
The biggest learning on my part is that I need to worry less about thing going wrong in my absence. My team is made up of some very capable people and are able to provide good guidance on how projects should be executed. I will probably look to see how I can take advantage of that to get some of them to provide more leadership. From a personal point of view, the vacation has enabled me to recharge my batteries and come back with renewed energy. I will also look to ensure my team gets the same opportunity.
It is good to be back. Keen to hear your learnings from similar experiences.
Image Credit: NewHotelsUs.Com
How many times have you heard that? “Oh, I’m not going to hold you to this, but just a ball park figure?” Sounds even more familiar? And now the clincher, “You know our systems, surely you have an idea.” Trying to answer this sort of question from the client too soon causes enormous headaches in projects.
Cost is something that is never a black and white answer. Cost of the same project will differ markedly depending on what technology and process choices you make, what functional and non-functional standards you sign up to, how much of the subject matter expertise your clients are willing to provide to the project team and even some mundane things like what time of year you want the project to be implemented. A cost estimate therefore must accompany the scope, assumptions and conditions that it is based upon.
Many times you will have technical staff working with clients that will be put on the spot by these kinds of questions. They will have the best interest of the client and their own organisations by trying to answer the question. Unfortunately, this sets the expectation of cost from the client’s point of view. Some of the technical staff may be very skilled in their own responsibilities, but may lack the full project life cycle knowledge. Therefore the risk of underestimating or completely missing required activities is high.
In all likelihood the client has not had the time to frame what it is that they want. If they have a figure to go by, they will form the scope in due course and wrap that around the figure. This happens inevitably, even if there is significant gap between any cost figures you may have provided and when they had the time to form scope. There may not be any malice involved at all. This is how we as human beings operate – piece together bits of information to build the picture.
If you try to reset the expectations of the client at this point, it is tricky. There is always a chance to give the impression that now that they are interested, you are trying to squeeze them. Chance to set the correct expectation has long gone. By trying to be helpful, you have a situation on your hands.
You may come up with the same situation with your sales staff as well. They may be the ones that are responsible for communicating costs to your customers. Your challenges will be equally as pronounced if they miss the caveats. There is a fine balance between the cost appetite a customer has and the benefits they wish to gain from a project. In the quest of landing a sale you should not set a project up for failure. If the project is a keenly desired one for which your organisation is happy to make a loss on, then your management must be in a position to knowingly take the risk on. This should not come as a surprise during the project.
How can you go about ensuring the correct expectations at the outset? The first thing I make a policy on is to never provide estimates on the spot. I have only seen bad outcomes in trying to do that. Have standard estimating methodologies that you follow. The methodology may be different depending on the type of project you are managing – i.e. software development, construction, policy development etc. But there must be a methodology. Document the risks, assumptions and constraints that accompany the particular estimate. This way once the customer has had the time to think of the whole solution and the cost is different than the first one you provided, you can have an open and honest discussion on why that has transpired. This must extend to the whole team. Train them to tell the client that they will take the information back and follow up with an estimate.
First impressions do last long with customers – especially when costs and timelines are involved.
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.
