| Being a top IT contractor doesn't always mean you | | | | software. |
| will be a good leader of IT contractors. Technical and | | | | One common reason is poor requirements gathering, |
| managerial skills are different. Here are some top tips | | | | resulting in the developers not really finding out what |
| to help you lead teams of IT developers successfully. | | | | the users what they want until something is built that |
| Meet the requirements: | | | | they can use. |
| Once you have established the set of system | | | | Focus on short iterations and getting software |
| requirements make sure you only build those, nothing | | | | released as early as possible, to obtain continuous |
| more and nothing less. Very often you find | | | | feedback from the user. It mitigates the large risk of |
| developers who like to 'guess what the users want' | | | | building the incorrect thing - which is the largest risk |
| and 'build things that are 'very cool'. I'm sure you | | | | most projects face. |
| know the type. Try not to fall into this trap. | | | | Know your team: |
| Instead try to build a culture where creativity and | | | | Get to know your team. Every software developer |
| suggestions are actively encouraged, but ensure that | | | | is different. The productivity rate of one developer |
| those suggestions are passed to the requirements | | | | could be up to ten times quicker than another. Some |
| manager. | | | | will tell you the task will take 'another 5 minutes', |
| How would your developers feel if they went back | | | | when in fact the reality is a week. Some like to build |
| to a garage to pick up their car after a basic service, | | | | a Rolls Royce when only a Mini is required. Some will |
| to find that the garage had decided to upgrade the | | | | write code that has more defects than others do, |
| engine to a new one, and that it would cost 5 times | | | | and isn't fit for release. Others will spend too much |
| as much and not be ready for another week? | | | | time focusing on fixing minor bugs rather than moving |
| Manage Risk Early: | | | | onto the major ones. Some developers don't test |
| Establish the project risks, manage them, and | | | | their work. And so on. |
| eliminate them. This is the role of the team leader. | | | | Know your team. If you don't know your team then |
| Building a piece of software is like trying to rob a | | | | their 'surprises' will present a risk to your deadlines. |
| bank. You don't want to get caught by the cops. The | | | | Time Estimates: |
| cops in a software project are all the risks that will | | | | Many developers do not include development, build, |
| stop you achieving your goal. These risks will range | | | | integration, debugging and testing into their |
| across the board from requirements risk, to | | | | estimations. |
| environment risks, to technical risk. | | | | To avoid surprises at deadline dates make sure the |
| Write down all the project risks, and make sure | | | | developers give you time scales that include the |
| everyone in the team knows what they are. Mitigate | | | | whole life cycle. Write down their estimates and get |
| them as soon as possible. | | | | buy in from them. Use them to feed into subsequent |
| Keep it simple - no "future proofing": | | | | estimates. Help them to become much better at |
| Keep the design of your code simple. Build only what | | | | providing you with estimates. |
| you need right now, and avoid 'future proofing'. Many | | | | Make sure estimates from developers include the |
| developers like to try and design the most flexible | | | | whole life cycle. |
| solution to a problem that will future proof them | | | | Manage Your Problems: |
| should the user ask for a, b, c and d etc. This is a | | | | Make sure you keep track of all issues and project |
| bad idea. | | | | risks, and also track your defects. Prioritise them and |
| Complex flexible solutions take much longer to write, | | | | deal with them accordingly. If you don't formally log |
| are hard to debug, are expensive to maintain, and | | | | them, they will get lost and you run the risk of not |
| the user hasn't even asked for them! | | | | resolving some important issues raised. |
| If the users ask for a Mini, build a Mini. Don't build a | | | | And finally: |
| Mini with a Rolls Royce under the bonnet. Keep it | | | | Remember that developers are human beings, not |
| basic and build the simplest solution that meets the | | | | numbers. They need to be cared for and looked |
| requirements. | | | | after. Don't work them too hard all the time, and |
| Feedback, Feedback, Feedback: | | | | when you do, allow them to rest. Stand up for your |
| The majority of money spent on software projects | | | | team, and they will stand up for you and want to do |
| is spent after they have been released, and are | | | | a good job for you. |
| spent on changes and enhancements to the | | | | |