Advice on leading a software development project

In My Humble Opinion
1

I started working for my current employer several months ago. It is a huge technology company that produces certain high-tech equipment. Their product is quickly evolving with increasingly complex features, and their development effort is shifting from just embedded software development on the gizmos to also include some fairly hard-core software that runs on a PC and interoperates with the gizmos. They hired me because this is an area that they know nothing about and I have a lot of experience in. I spent the last several months getting myself acquainted with the company and the product and getting the project defined. We’re now at the point where actual development will begin fairly soon. I’ll be leading a team of about 10 - 15 engineers on a project that will last about 9 months. None of the team members have done this type of work before, and most of them only have a few years of experience. As can be expected in this type of situation, a few are very bright and should have no problem picking up the new materials at all. Some are unremarkable. A few are completely useless and cannot be trusted with anything important.

I’m starting to get a little nervous. This is the first time that I have been given this level of responsibility. It also doesn’t help that this is a new job and we’re still getting to know each other, so to speak, so failure isn’t an option as far as I’m concerned. If anyone has been there and has any advice, that will be greatly appreciated. Also, if there is any recommendation on good books about leading and managing software development in general, that will be great too.

Thanks.

2

You need to be able to talk to the (internal) customer, and understand what they care about.

3

You will have to become completely familiar with all of the product’s technical features, and I mean to the point of being able to build it by yourself (given enough time) as if you were the only person in the world able to do it. Anything less than that means you’ll end up relying on someone else to make technical decisions for you in areas you’re not familiar with, which is NOT why you were hired.

Now since your division doesn’t have an unlimited amount of time to create this product, you will have to delegate portions of this project to the engineers best suited for the work. You’ve already determined certain levels of ability amongst the team members, but you will also have to balance out how much time all team members will take for tasks overall. It will be no good if you’re always relying on your brightest team members to fix the thorniest problems just because they can do it fast, since they’ll be further developing their skills and doing things quicker while the less talented members languish and keep doing things slow. Part of your responsibility as technical lead is to raise the skill levels of all your team members. Remember, “A rising tide lifts all boats.” Spend time with the less gifted members teaching and training them. Try not to give them the answers they seek. Instead, teach them how to go about finding the answers for themselves. Get the more talented team members involved in this process too.

Be prepared to be called on the carpet by management for missing deadlines. ALWAYS have you ducks lined up and have your decisions documented to show them why you made them. If you’re doing your job right, the fault for missed deadlines almost always falls with someone outside of engineering (management changing requirements, sales overpromising deliveries, outside vendors providing buggy tools, etc.). You want to show the company that they made the right decision in hiring you and that you always make the correct technical decisions, based on sound reasons.

Finally, be ready to throw all this advice out the window and do whatever it takes to get something done if management has set an “absolutely cannot miss” deadline (you will have to discern whether or not a deadline is “miss this and the company folds” vs. “miss this and the sales team loses its year end bonus” type of deadline though).

4

Poor performers:
“You can’t turn a goat into an eagle” - get them out of the way so they don’t slow anything down.

Delegate:
Give your smart guys the room to get stuff done, don’t try to control everything - but do make sure decisions are pragmatic.

Deadlines:
Cut stuff out now. Keep it simple. Come back and add later.

5

Work out a way to create a prototype of the product. Don’t worry about full functionality, it’s just a learning tool. The biggest problems you face are the things you don’t know, and won’t find out about until you try it. Before you are done you will certainly find several of your initial ideas have to be reconsidered and reworked, and this is the way to minimize the resources consumed in discovering which those are.

You haven’t provided a lot of detail, but also start with the concept of ‘Top down design, Bottom up implementation’. In your case this probably means design your system in terms of the user interface, what functions are available, and how to navigate through them. That’s just a design phase based on what the users would want to see. In implementation though, those designs won’t work unless your assumptions about the lowest level of functionality prove out. Your talking about controlling gizmos, so in implementation make sure each low level gizmo functions works as you expect.

So slap something together, with low expectations, and then review what you’ve done with a dispassionate and critical eye. The second go round is where you make the reality. It may not be as fun, and you may need to rethink the personnel based on your experiences developing a prototype.

Also, avoid mission creep. Start with the idea that you don’t have enough time to get the job done based on initial specs, and fight back against adding anything new. If management insists on new functionality, insist on additional time and resources to take them on.

A small trick, set goals (deadlines) for steps along the way, and set your deadlines for Mondays, not Fridays. If you are lagging, you can jam over the weekend to get things done for a Monday delivery. Get your team used to stretching to achieve those short-term goals to avoid the idea that everything will come together on the big day at the end.

Finally, when you are done, you aren’t. Inform management that you need to start a Quality Control process to test and debug your product. In reality you’ve been working on this all along. Don’t rely on a programmer to test his own code. Instead, as you build up the system from the bottom, have the programmers develop the method of testing the code their module depends on.

6

From over 30 years of experience in this.

Number 1 thing - get specs. Make sure they are written down, but not to the level of detail which will make your internal customers eyes glaze over. One problem I have seen is that non-programmers have no idea of how their little tiny change can screw up a project, and also how some things might be easy to change. Getting them to commit will be like pulling teeth, but an investment in listening to them, telling them what you heard, and repeating it, will pay off big time.

Numero two-o - as TriPolar said, have something to show them, and have it quickly. The hard part of the code will likely be implementing stuff which is pretty solid, stuff like the UI will be the things they want altered, since they will not know what they want until they see it, and sometimes not even then. The prototype is actually part of the spec, but helps in that your customers will understand better that you are making progress, and your team will see some real feedback.

Three. Understand the skillset of your team, and break down the job accordingly, not forgetting the people doing testing, who should be starting to define and write tests when the coding starts. Get estimates for completion from each. My heuristic was to double it and add 2 weeks, but you might not have that luxury. Have plenty of visible milestones to track progress - visible meaning a function completed, not something like “coding 90% done.” Make this very visible. When I was in grad school I did 90% of a quarters work in the week before our quarterly report was due. Use project management software if you must or if it gives you a warm, fuzzy feeling, but remember that this software doesn’t do a good job predicting debug or handling rework, and so you management might consider the end date it predicts the truth, and not a wildly optimistic guess.

Do code reviews. You probably shouldn’t attend, but get your best and most confident programmer to start. This will make it clear that getting ones code review is not a punishment, and also starts with the biggest plus for code reviews, which is the good programmers teaching the not so good programmers how to do it by example.

As for you, the three best things you can do is to understand how everything fits together, and make sure that your staff don’t make design decisions that locally optimize their part at the expense of the project; worry: that is, think about things that might go wrong and might be forgotten, and try to ensure that you’ll be okay if they do; and protect your team from one more change or from being taken away temporarily for “more important” jobs. Oh, and track completion dates and bugs, so you can do better next time. And if you must make a change in the middle, estimate the schedule impact, get on the agenda of a top person, and ask them for formal buy-in for the slip. They may tell you to work smarter, but if you have been delivering your first milestones on time they may actually rethink the oh-so-important change. If it is really that important, they will at least know a realistic delivery date, and if you manage to beat it the better for you.
Oh, and whatever you do, don’t overpromise. That is hard for a new project leader to get - until you can’t meet your promises. Underpromise and overdeliver is good advice.

7

Some really great advice in this thread.

What do y’all think about Agile/Scrum methodology?

8

Scrum is awesome, especially in a situation where you’re not dealing with oursourced developers. I highly recommend it, when it’s running right it’s like being a conductor leading an orchestra, instead of a shepherd herding cats… One note of caution - upper management looks at Scrum as one of two things; either a waste of man-hours, or an opportunity to micromanage on a daily basis. Keep upper management away from your scrums, and ideally away from your developers. Dealing with the world is your job, let the developers do theirs without interference.

9

Know (or set) the expectations (internal and with the customer)

Define requirements (internal and with the customer)

Lots of communication (internal and with the customer) - Surprises are bad!

Be able and willing to say no to scope screen/changes (or perhaps a “yes, with a cost and schedule impact”)

10

It works well when:

There is a clear mission. To keep an effort focused there have to be arrows that show the way based on the business factors. Many choices have to be made based on those factors rather than technical issues. In order for the technical team to make those choices they have to be able to see how well alternate solutions follow the course that has been set. In the end, that will be the basis for management’s evaluate of the results and the process.

You have the right people. People are different, and some don’t work well in the fast paced development environment. You need people who are flexible and don’t have a narrow comfort zone. To make things work, team members have to fill roles needed at a particular stage of development instead of their specialty roles. You also need some people who are fearless. Nothing slows down an effort like hesitation in the face of adversity. That adversity may be the process of adapting to new technology, or another poorly thought out requirement forced in by upper management. But somebody has to wade in first to show that the water is not too deep.

The project has to be suitable for this type of development. The project has to involve development of a tightly coupled system that cannot be completed in a reasonable time by a very small group of people. If the system consists of mainly independent components that could each be developed by very small groups, that may be the better approach in that case. Large scale, complex teamwork is always more difficult to implement and less efficient than individual or close-knit team efforts, so the project has to warrant the overhead involved. And the need for this type of development may change over the life of the effort.

11

Stuff that will kill you:

Shifting requirements. Sales and management need to state the requirements at the beginning, and be available for clarification, then STFU and let the team do the work.

Micromanagement. If you think having the entire team meet every day for an hour long status meeting is a good idea, your project is doomed, and you need to be shot.

Blame assignment. If you make the consequences of failure high, then team members will focus on covering their asses instead of solving problems.

Similarly, if you manage by risk minimization, then the best case result will be a mediocre cook book product that anyone could have done. Take risks, and manage those risks by having a plan B, not by shooting down the plan A from the start.

12

Thanks for all the great advice so far. They are all greatly appreciated.

Regarding the issue of management/marketing changing the requirements on a whim that many of you brought up, I guess I do have something working to my advantage. This company puts a lot of emphasis on following processes. Everything must be defined up front with official buy-in obtained from everyone. While that approach has some major problems of its own and is very inefficient, there is a well defined change process (i.e. a lot of red tape) that management must follow before ‘just that little extra feature’ can be approved into the release. I hope that is enough for me to justify telling people no!

13

Voyager already provided most of the detailed advice that I would offer. I’ll be more general and say that you need to adopt a systems engineering framework and stick with it, regardless of the upfront cost. It doesn’t really matter which framework it is (for the most part, it is mostly the same set of methods and tools with different nomenclature) but you need to establish the roles and responsibilities, requirement allocation and adjustment, and whatever working structures you need to manage and measure your progress. Train someone (preferably more than one person) on a formal requirements allocation and tracking software like DOORS, and make certain requirements are clear, traceable, verifiable, and practicable, which includes a solid system requirements analysis cycle. And then, cut your requirements loose to individual developers or teams, and only management by tracking compliance and established technical performance metrics, not by day-long weekly status meetings or micromanaging their daily activities. Accept that this is going to generate a lot of apparently needless work (although, for blob’s sake, minimize the amount of formal presentation and other oxygen burning, paper churning activities that have no output or value other than impressing upon higher management that you are providing the image of progress) and recognize that preventing rework is more valuable than doing nothing.

I’m not sure of the criticality and reliability requirements of your project–in the aerospace/launch vehicle field in which I’m experienced, there is no latitude for uncaptured error–but it is better to spend the time upfront to assure that your testing and quality assessment regimes prevent finding a nasty error in the end product just prior to launch. You either take the hit upfront–where you can recognize unrealistic requirements or approaches and fix them in the beginning–or you take it in the ass when it is too late to effectively fix them and end up patching over bad decisions.

Agile/Scrum is great in prototyping (in aerospace terms, before the Preliminary Design Review); once you have both a fixed set of requirements and a provisional detail design that meets those requirements, you need to fix it in stone and start chipping away at the details rather than continue to modify. Also, you need to have formal working groups or integrated product teams or whatever you want to call them, which have a charter, scope, expected products or responsibilities, and most importantly, a termination date after which they are disbanded instead of lingering on and interfering in things just to justify their own existence. “Perfect is the enemy of good enough,” is a motto repeat on a daily basis. You can always go back and refine as a cost saving or process improvement measure, but if you insist upon the first release as being without any flaw you’ll never release anything.

Also, just because it is a personal pet peeve of mine, when you have meetings, they should have a leader/mediator/facilitator, agenda, objectives (products or actions to result from it), and a hard time limit that is stated up front. Even open discussion type meetings should have a limited duration; after a coupe of hours (or less) such meetings typically end up with people riding their hobbyhorse issues or repeating things over and over until they bulldoze their way. In my ideal work, meetings last only half an hours and exist solely for the purpose of conveying information between multiple parties and achieving concurrence. This isn’t possible in the case of formal design reviews, but many technical interchanges, status meetings, and working groups seem to be little more than two or three people vying for attention rather than coming to a conclusion or concurrence.

Stranger

14

Yes, we also use DOORS to manage requirements. This is all very new to me, but I am working closely with some system guys who understand the bigger picture and they’re helping me get started.

Officially, the tier of products that I’m working on is not supposed to be used in mission critical applications. There is a higher tier of products from our company (which are also much more costly) that are intended for just that. However, the reality is that some customers are deploying our product in mission critical applications anyway, especially in many developing countries, so we do at least try to invest some extra efforts into reliability.

15

A few things I have learned over many years in various development roles:

Don’t let the problem be you. Assiduous honesty is the first requirement for a project manager. I have been involved in too many projects where the engineers think things are going badly but the manager, because he gets pats on the back for being on time, tells a different story. Then in one week the project suddenly goes backwards 6 weeks.

Accept the fact that good engineers can produce 5 times as much usable code as average/poor ones but use the good ones to boost the output of the others. Let them know that you appreciate their skills and ask them to mentor some of the less able by spending a portion of their time helping out. We do this where I work now. Any one of the more skilled people can happily butt in to someone else’s work to check it out. Beats finding a fuck up way down the track and no-one gets precious about it.

No matter how enthusiastic the team is at the start of the project there comes a point where it just becomes a slog of grinding out code. And software development is hard work - heavy duty thinking, problem solving, problems themselves and an ever rising stress level as the project continues. This is the point where things start to go wrong.

The only thing that seems to make a difference is making work fun. I worked on a project with Arthur Andersen. Of the 4 teams on the project mine was the loudest, rudest and laughed the most. At one of the project meetings another team manager complained that we were annoying. The project manager said he would tell us to quieten down, except we were delivering fully functional product twice as fast as every other team. I think it’s even worth scheduling regular fun activities of your choice - a quick bit of PC gaming, minigolf, we throw nerf type stress balls at one another, lunches, be imaginative.

Keep meetings to a minimum. Mostly only 1 or 2 people need to know where I am up to. Quicker and easier for me to send everyone an email. Those that don’t care don’t have to read it. Also in keeping with the, make the project fun ethos I think now I would set up a project Twitter account to let people update, boast, blow off steam, whatever.

16

Scope creep (‘featuritis’) is a real killer. As Project Leader, a big part of your job is killing this off, so your programmers can keep busy producing code. (And note that sometimes programmers can be as guilty of dreaming up new features as users!)

A good way to fight this is phased development.

Early in the project, get everybody to agree that it will be done in multiple phases. A good time to get this agreement is just when the first development estimates come in, and the users are upset to see that it will take longer and cost more than expected.

Suggest that we do a minimal basic system, that we can get up & running in a shorter time at lower cost. Minimal, by cutting out some features, that are delayed until Phase 2. Those are done when Phase 1 already running and providing payback – and Phase 2 will be in next year’s budget. Often this is not that hard to sell to your users.

Then, during development, you must never allow anything to be added to Phase 1. For every new feature somebody dreams up, you say “Great idea! We’ll add that into Phase 2.” Make that satisfy them, and your programmers aren’t bothered with late additions or changes.
And, in my experience, most Phase 2’s are never done.

Once Phase 1 is in production and being used, the users often discover they don’t really need many of the features of Phase 2, or they need different ones, or that the basic Phase 1 provides most of the benefits, and added benefits of Phase 2 features can’t be cost justified. So only a few of the Phase 2 features are worth doing. Besides, the managers are now looking at a new big project, and have lost interest in Phase 2 of this system.

17

Wow. That is very clever trickery and, better yet, adaptable to anything you are working on, even little ad hoc requests.

18

What is your role - i.e. by “lead” what do you mean?

Successful development projects usually have a project manager who manages the nagging details - if you go Agile, get one who knows Agile - waterfall project managers get all confused with the iterative processes. Also, get a SEPERATE Business Analyst. Too often its expected that the PM will be the BA or the BA can PM in their spare time. A good BA is a completely different skill set. A good BA is the one that can turn customer wants into executable requirements.

19

I agree with all of this, but here is one more trick. After each meeting, reserve about five minutes where you go around the room and each participant gives feedback about how the meeting went. I’m sure everyone has gone to meetings where you walk out muttering about what a waste it was. The time to say that is in the meeting. This method turned a very useless meeting to a very productive one. In the very beginning this may take a long time, but when you have things stabilized it should be fast.

20

I am starting a new project next week and the client uses Agile and Scrum.
The suggestions here are VERY appreciated and cogent (as expected).
Thanks!

Great OP by the way.