Planning Genius or Stupidity?

Posted on May 10, 2012 by

Here’s a little story of a project I was recently involved in. I always enjoy the chance to watch and learn from other people’s work, so with an external Project Manager I was looking forward to this one.

Things started well with all parties coming together to form the project plan. One thing that stood out on the plan was that it didn’t include any testing to show that the implementation had been successful. Whilst this concern was raised, nothing changed. Otherwise, the plan looked reasonable with various check points and milestones along the way.

Everyone signed up and off we went, full of optimism and ready for the challenge.

Pretty soon we hit problems, certain tasks were delayed and unexpected items cropped up that needed to be dealt with. Nothing too unusual there, however, instead of re-planning or executing contingency plans we simply proceeded as if nothing had changed and pushed on as best we could.

I was amazed that the original plan still stood, but even more amazed that the go-live date of the project was still achieved. Was the PM a genius for getting it this far or was he stupid to ignore the warnings along the way? I’d have been pushing hard to act upon the various setbacks we’d had on the project. Questions such as “Can we have more time?” and “What items can we cut from the first phase?” would have been asked. My approach would have been to get the bad news out early and reset expectations – better to give all the stakeholders as much warning as possible and opportunity to adjust their own plans. But maybe that wouldn’t have been right, after all this project still achieved its go-live date without having to change plans or cut items.

Well, having spent the past few weeks living through the consequences of this false go-live, I’m pretty sure the PM was not a genius!

All sorts of senior people got dragged into a project that they didn’t need to be involved in. If the original plan had considered how the end results would be tested and assessed the risks of needing some time to adjust the solution then additional time for user acceptance testing and rework would have been added and the eventual timescales would have been about the same. However, instead of creating the extra stress and bad feelings, everyone would be pleased to see the project on plan!

Here’s where I think the project went wrong, and I think this is a common mistake. A project plan is your best estimate towards reality. It is there to help you make sensible decisions that you otherwise couldn’t make unless you knew the future. A project will always take as long as it takes. Always. That’s worth repeating, a project will take as long as it takes. You might not like that fact, but it is a fact nonetheless. Your plan has little influence on the time a project takes, so you are best getting the plan as accurate as possible instead of as short as possible. Of course you can change the parameters of a project; deliver less, lower quality, assign more people, but these are so much harder to do once you have published the plan and formed a commitment to the stake holders. Your skills as a PM are often judged on how close you can make reality fit your plan, but really all you’re actually judging is how well you produced the plan in the first place!

The warning signs were there throughout the project – tasks were 90% done, but not complete. Everyone reported only what they thought the PM wanted to hear, not the truth. Once the project became live, there was nowhere left to hide and so it wasn’t pleasant viewing.

So here are the lessons learned:

1. When starting a project consider the end goals and how you will check if they have been achieved or not.

2. Look at the risks to achieving those goals and make contingency plans. In this case running a backup system whilst the new one was being tested and reworked would have been a good plan. Alternatively, scheduling representative groups of users to trial the system in phases would have been a better alternative to a big bang where the whole project was either a total success or total failure.

3. Seek the truth on a project no matter how unpalatable that might seem. Request honesty when dealing with progress and risks, and reward that honesty instead of instilling a fear of failure.

Posted in estimates, information, listening, planning, process, Project Management | Tagged , , | Leave a comment

The Talent Code

Posted on March 31, 2012 by

The Talent Code

I’ve recently finished reading, The Talent Code by Daniel Coyle.

Here’s my summary of the key points and how I think we could use these in software development.

I’m a definite subscriber to the idea that the best software developers are 10x more productive than the worst.  I’ve seen this in practice with the people I’ve worked with and there are numerous studies that have produced the same results.  The interesting thing about The Talent Code is that it offers an explanation and to how some people can be so much more productive than others.

I’m a big fan of programmers who started programming early and the idea put forward by Daniel Coyle that it takes 10,000 hours of deep practice to become world class would support that reasoning.  Note that 10,000 hours on its own is not enough, it has to be deep practice, and to maintain that practice requires ignition (a spark to light the desire to succeed) and master coaching.

Rather than just accepting that some people have a talent for programming,   Coyle provides a blue print for gaining that talent that doesn’t require an innate ability to start with.

Some of the current practices that I see within the development community can be directly linked to the talent code.  Coding dojos, and Coding katas both promote the idea of deep practice.  Not just slinging together the quickest solution to a problem to get the code out the door and the boss off your back, but really thinking about the problem and pushing your brain to grow more talent.

Sharing the experience, and being inspired by great speakers is a way to ignite the desire and maintain the will to keep learning and practicing.

Agile practices such as pair programming offer the opportunity to examine the work of your pair and really think about the problem, what you are producing together, and ultimately learn from the experience.  In short, they offer the chance to grow myelin, the secret ingredient to talent.

Retrospectives also invite learning and continual improvement.  Rather than repeating the same mistakes, retrospectives offer the chance to suggest change, try new things, practice better and therefore grow more talent.

So whatever you are doing and whatever your skill level, if you want to improve, you should be doing something you enjoy, you should do it a lot, but most importantly you should really think about what you are doing.

Posted in peopleware, reading, software development | Tagged , , , , , | 1 Comment

What Makes a Good Manager?

Posted on December 18, 2011 by

I have worked with many managers over the years.  Some of them I have found inspirational, others absolutely unbearable, but I’ve tried to learn from them all.

So, what is it that makes a good manager?

Well, here’s my 5 point score for ranking managers:

  1. Understands people
  2. Is one step ahead of the team
  3. Organised and can handle interruptions
  4. Determined
  5. Honest

The first quality I’ve identified is the ability to understand people.  Management is really all about people, so a good manager needs to be able to work with other people.  When managing developers I believe empathy is the best approach, you must be able to see the world from their position (and developers can have some odd views on the world!).  However, empathy is not the only way to be a good manager.  I have seen several great managers get the tasks they want doing using psychology and salesmanship.  They can find a problem and sell a vision of how to solve it that the team will follow.  This is a good technique to have available, but as soon as someone sees through the sales process or the vision you sold them turns out to be a lie then you may never gain their trust again.  So use this with caution and only when you also truly believe in the vision as well.

The second ability I’ve recognised is in being one step ahead of the team.  As a manager one of your main responsibilities is to keep your team moving forward.  You should be clearing the roadblocks, identifying the risks to progress and trying to remove them.  To do this you need to be thinking about them before your team runs into them.  Of course some problems are going to come from nowhere and no amount of planning and forward thinking is going to help you.  In this case, you need to be available to handle interruptions and think on your feet to deal with them.  Keeping organised is going to help make sure you don’t miss any of your commitments and actions.  I’d definitely recommend something like GTD for this.

A manager has to be incredibly determined.  They carry the weight of the team and need to drive it forward in the most difficult of circumstances.  If they lack determination, the team will lack determination.  This leads to an acceptance of second best, and can quickly degenerate and destroy the team.  For more information about Broken Window Theory see this excellent post on Coding Horror.

Note that I’m not advocating blind faith.  Projects can and do fail, and recognising when they do is a skill in itself.  Continuing a Death March is no fun and one your team will definitely not thank you for.  You need to be determined enough not to accept defeat at the first hurdle, but not so determined that you waste time chasing a lost cause.

The final attribute that I think is essential is honesty.  If you are ever caught lying then all trust you might have had will be lost.  Without trust you are going to struggle.  Trusting your manager frees you up to simply get on with the job you should be doing.  Distrust leads to questioning every decision they make and is definitely going to distract from whatever it is that you are trying to achieve.  So a team that trusts its manager can focus, a distrusting team cannot.

So, there you have it, 5 qualities to look for in a good manager.  There may be other things that you also think are important, but for me, these are the 5 things that stand out.  Why not let me know if you think I’ve missed something or you disagree with any of the 5 I’ve chosen?

Posted in motivation, peopleware, planning, process, Project Management, time management | Tagged , , , , | 5 Comments

Risks

Posted on November 6, 2011 by

I remember being a technical lead on a project and working with our project manager and his newly introduced risk register.  Something bothered me about that risk register and the way it was being used and I’ve recently managed to figure out why – it wasn’t effective.  The process was good, identifying risks and planning mitigation strategies and contingency are some of the most important tasks of a project manager, so why didn’t it work?

I think the issue was in the identification of the risks themselves.  Whilst you can define a risk as anything that could affect the progress or outcome of a project, I think this definition is too broad.  Seriously, anything that could affect the project? The bubonic plague making a comeback would seriously affect the team, but probably isn’t worth tracking on a risk register or making contingency plans for – unless of course you happen to be working with infectious diseases!

So that was the first issue – identifying risks is hard as the risks need to be relevant, not just a big list.  Quality is definitely more important that quantity.

The second issue was in the plans he made to mitigate the risks.  A major risk identified was staff leaving and taking their knowledge with them.  Not only did this fail the first criteria of not being likely (the team had been together for years, and no-one had left in that time), the mitigation plan was harmful to the progress of the project.  People weren’t allowed to specialise, areas of the product were constantly moved between developers, extra (unread) documentation was produced, and presentations were performed to uninterested participants.

Now maybe I’m just lucky, but reading other team members code is not hard.  If someone left, the team would take a hit, but we’d soon be back up to speed.  Before a single line of code was  written on the project, the team discussed coding standards and agreed on a way of writing the software.  This common style made the code a lot easier to read and understand as even previously unknown areas felt a little familiar and welcoming.

So, the risk of someone leaving should have been classified as unlikely (even 8 years later the same people are still on the team).  The impact should have been classified as low with no need to change the working behaviour at that time.  It is ok to monitor the risk to make sure that these classifications stayed the same, maybe people would be more likely to leave, maybe the code being written becomes to specialised and key people start to emerge, maybe retention plans need to be put in place to encourage certain people to stay.  It is also ok to have thought about how to deal with a risk before it occurs (contingency planning) so that the way of dealing with it has already been considered.  A plan that covers how to transfer areas of knowledge if someone hands in their notice is a good one.

Overall we need think about how it helps the team progress.  A risk register in itself is not enough.  It must be used correctly, it should take the panic out of projects, both in avoiding risky areas that are unnecessary (some risky areas may be needed for the success of the project) and in dealing with issues as they occur (as they have already been thought through).  It should help set realistic expectations; instead of guaranteeing certain deliverables the project manager can identify a range of outcomes based on the risks to the project.  A risk register that isn’t helping the team should not be used.  A risk register that is helping the team can be a great tool.

Posted in planning, process, Project Management, software development | Tagged , , , , , , | 1 Comment

Update

Posted on September 21, 2011 by

It’s been a while since my last post, so I thought I should try and fill the gap a little.

I should have been posting my discussion on Risks; what they are and how to deal with them. However, having hit the word limit on the post I was writing on my Windows 7 Phone, I somehow did the wrong thing and lost the lot! Maybe one day I’ll be able to bring myself round to writing it again, but not at the moment.

I’m still going to use my phone to write my posts, but I’ve switched to using One Note and Skydrive to back it up (free with my phone).

I’ve also been spending time learning a bit of ruby as part of the excellent Nottingham Digital Events.

I’ve always had a need to do more than the usual 9-5 work thing and have a couple of projects I’ve been tinkering with for many years.  I’ve recently dusted off one of these projects and have started adding a bit of web presence to it by trying Webmatrix. This is the first time I’ve really looked at any web development and my first time using C# to any great extent. I have to say I’m really impressed with both Webmatrix as a platform for getting things done quickly and efficiently, but also C# as a language.

Perhaps, I’ll give some more details in a future post, but for now I just wanted to post something and let you know I’m still alive!

Posted in Meta, News | Tagged , , , , , , , | Leave a comment

Software Develpment and Customer Support

Posted on July 8, 2011 by

Here’s something that has bothered me for a while – being able to manage a software team which involves keeping on track with new developments whilst still supporting our existing customers.

First, a quick look at the history of the team and how we have managed these needs, then I’ll describe our current situation and add my thoughts on what we should be doing.

Many years ago, I worked as part of a software development team who worked on development contracts for customers. This placed emphasis on specifying the work to be done upfront, producing defined deliverables and test plans to confirm acceptance. Support involved agreeing to fix any reported defects for a fixed period – typically 6 months from delivery. Anything extra was chargeable and generally that was enough to stop any further support requests. One theory would be that we wrote better software “in the olden days”, but that isn’t one I would subscribe to.

The big change for the company and the development team was producing our own product. Initially, this was sold through a 3rd party who did a fantastic job of documenting, installing and supporting the product that whenever a defect came through to the development team, it had already been investigated, diagnostic information collected and was ready for a developer to resolve.

Once that layer of support was removed the quality of defects rapidly declined and developers had to get more involved in just figuring out what the issue was. Resolutions often just involved informing the customer of the correct way to perform an operation or the need to adjust external components not provided by us. However, we didn’t have many customers and this extra load was not too much for the team. We could offer amazing levels of support – just imagine ringing a company and being able to speak with the company expert (the person who wrote the software) about your particular issue!

This was fine for a while until we got too many customers! We couldn’t handle the amount of questions coming in without seriously affecting our ability to develop new functionality. We lacked the documentation, the installation skill and the support personnel to deal with this load.

I’ve outlined the 3 issues right there, so addressing those should be easy right? Wrong! It’s a huge cultural change to address those issues. We have taken steps in the right direction, but we still have a long way to go. We have an Operations Manager with a dedicated installation team and a full time support team. We have a Pre-Sales team to help bridge the technical gap and prevent some of the installations issues before they leave the design stage. We also have a Product Manager to help address the lack of documentation, but the increase in customers is happening quicker than those new roles and teams can keep up with.

Some indication of how much of an issue this has been can be seen in my previous post on changing managers. The first Operations Manager didn’t have enough of an impact and so we are now trying a second manager.

As part of the support team we have 4 developers seconded to the Operations Manager. This creates an issue, how does the Operations Manager manage software developers? Isn’t that the role of the Software Development Manager? Perhaps a more helpful question is why does the Operations Manager need a team of developers at all? Well, our software isn’t perfect, so we accept that a certain level of development is required to address the needs of our customers, but that still doesn’t answer the question.

The reason the Operations Manager needs software developers is that Operations is woefully under staffed. We are using developers to investigate and resolve issues that don’t need a developer to resolve. We are asking them to answer the telephone, we are asking them to fill in gaps in the knowledge that should have been documented, we are asking them pre-sales questions, we are only partially using them as developers.

But isn’t support and the happiness of our customers important, so don’t they deserve to talk to the experts and not a clueless call centre operative following a script? Sure, if you can afford to do that, then go ahead, but as we’ve seen that way of working doesn’t seem to scale. However, I believe a customer would be equally happy talking with a specialist skilled in the art of communication who is equally capable of resolving their issues. It is those 2 skills that a customer requires – good communication and the ability to resolve their issue. Communication is not always a developers strong point and many issues do not require code changes to resolve.

We have a Product Manager tasked with delivering functionality into the product, but they have no developers with which to do it. So, why would an Operations Manager tasked with installing and supporting our customers need developers? The simple answer is they don’t.

We should recognise this issue, recognise that the time of developers covering support is over and make plans for moving them back where they belong – under the control of the Software Development Manager. To do this requires a drastic increase in personnel in Operations. Emails should be dealt with on the day they arrive – not 2 weeks later. Customers shouldn’t have to ask 4 times for a status update – they get them when they have been promised, and developers can once again focus on resolving faults that have been thoroughly investigated and documented.

Posted in information, peopleware, process, Project Management, software development | Tagged , | Leave a comment

Three Levels of Object-Oriented Programming

Posted on May 6, 2011 by

Everyone claims to understand Object-Oriented Programming (OOP), it is taught on nearly every programming course and is supported by nearly every programming language in general use. However, if my own experience is anything to go by, then there are very different levels of understanding as to what it means to practice OOP.

I’ll outline the 3 levels of understanding as I see them:

1. Objects represent actual objects

Most courses I know start by introducing the idea of objects being used to represent real objects. They are used to explore the more advanced concepts of inheritance and polymorphism and tend to use objects such as cats and dogs as the items represented as objects. Great theory, but I want my program to do something!

2. Objects as groups of functions

This is the answer to getting objects to achieve the goals of the program – group all those procedural functions together into something called an object. Now we can at least get something done and that is often enough to add OOP to our CV. However, whilst you may be programming with objects, this isn’t really OOP.

I will confess, this was my level for many years. I’d done the theory of OO on my University course, I’d joined a small team of developers writing C++ and risen through the ranks to the point where I was leading the team, but still our programs were little more than objects being used to group functions.

The turning point for me was reading Design patterns : elements of reusable object-oriented software

3. Objects as conceptual items

Having read Design Patterns I noticed a whole new way of using objects to get a task done. These objects represented conceptual items and worked together in such an elegant manner that I was embarrassed by some of the previous objects I’d produced! Being able to produce programs that make use of objects as a way to model real-world items, can get the job done and also model the concepts of the program is the level of understanding that OO programmers should be achieving.

Posted in software development | Tagged , , | Leave a comment