I'm a big fan of checklists. There is Travel Checklist, Moving Checklist and even a Scrum Checklist.

Context: you have been hired by a large corporation and given the mission to setup the whole software development environment, processes, team, etc. You have "carte blanche". You will be responsible for the creation of the working increments of the software. Project size: 2000 man/days.

What items would you add to the following (intentionally small and incomplete) checklist:

  • Install a Continuous Integration Server
  • Write a DoD
  • Write a one page coding guidelines
  • Create a product backlog
  • Install a Bug Tracking System
  • Schedule Regular Face Time

9 Answers 9


* 1.) Talk to the developers to see what they really need! *

2.) Investigate a solution for bringing up multiple environments really rapidly (think public or private cloud instances or old fashioned virtual machines if you'e not buzzword compliant)

3.) Source/version control

4.) Code review system (Crucbile/Fisheye as an example)

5.) Kanban wall (or something similar)

6.) Communication protocols (real time chat is a big plus), wikis also encourage collaboration. This also covers public relations internally - how are you going to engage with your business owners, tech support staff and other groups?

7.) Electronic whiteboards

8.) Comfortable environment for developers (couches, tables, chillout areas, good WiFi etc)

9.) Great coffee!!!

  • cofee makes the difference :)+1
    – RBA
    Commented Dec 3, 2010 at 13:28
  • what is the electronic whiteboards you use?
    – user2567
    Commented Dec 3, 2010 at 17:39
  • @Pierre 303 - Printing out the results of a white board session a (high-quality photo will do the same trick I guess). Commented Dec 3, 2010 at 18:00
  • Toolchain setup - IDEs, CI server, code quality server, source control, webserver, databases, issue tracker etc.
  • Backups - What role does each person in the team have? What processes/modules does he 'own' and who is his backup?
  • (User-Acceptance) Test environment setup - Not only continuous integration w. unit tests, but integration tests to cover the really bad things, multiple platforms, application servers, VMs, etc.
  • Performance Tests setup - The earlier the better, since you will need historic data to answer "With which feature/milestone did the performance drop so badly?"
  • (End-User) Documentation outline - What is going to be in the documentation? What type(s) of documentation is needed?
  • Marketing channels - How are internal milestones and external releases being announced? Do you have a cool name for the software, a logo, colors, wording etc.?
  • Internal communication - How are peers from other teams going to be informed about changes? How is collaboration being done? Wiki? Access rights?
  • Quality Assurance people & process - Who is going to test what, how often and with what criteria?
  • Release process - When, how often, how, who is doing it, who is receiving the release etc.
  • Risk management - Worst-Case Scenario (from a project mgmt pov and from a runtime pov, e.g. 'customer is losing money because software failed at module X, what is the backup plan?)
  • Securing of the core development environment, e.g. virtualizing it for Escrow
  • Locations for formal and informal meetings
  • Training or intros for all the people, so they know what all the setup is, what each part is for and how they use it.
  • Identifying the caretaker and give him all the things (e.g. permissions) he needs to actually take care of when things go bad
  • +1 for backups and training
    – Liviu T.
    Commented Dec 3, 2010 at 10:14
  • backups, althought I think some of this is extranious.
    – BlackICE
    Commented Dec 3, 2010 at 16:21

Postmortem Reviews - Since you are working on things in blocks, I would schedule a one to two hour review (depending upon team size) to have a face to face meeting (if possible) where everyone goes around and says what was done right, what could be done better, and what wasn't needed. Being able to learn from your mistakes in the development process early means that you can avoid doing them later on when you don't have as much time to work with.


Let's start with hire a good team of the right professionals for your project. In a typical business app you would need to hire a database developer and a dba, a QA person, a system admin, a business analysts,application developers, a UI specialist and team leads at a minimum. DBA, System Admin, business analysts and QA should be in a separate reporting chain from the development team. The development database specialist should report to the same technical lead as the application developers and UI specialist.

Set up the office space. Private offices are great if you can get them (I wish you lots of luck with this), but at a minumum you needs desks, phones, computers, whiteboards and a couple of dedicated conference rooms. Make sure there is a place for lunch breaks, a refrigerator, soft drinks, snacks, and coffee available. Free soft drinks and coffee even better.

Set up dev/qa/staging and prod servers for both the application and the databases. Databases should not ever be on the same server as the applications. Depending on the size and scope of the project, you may need multiple servers or SANs, etc for each environment.

As soon as servers are set up, schedule backups of the file sytem, the database and the database transaction logs. Do this the very first day things are set-up. Hire a firm like Iron Mountain to take backups off-site weekly.

Set up a source control system and create a document describing how it will be used. Do not forget to insist that ALL database structural changes and data inserts for lookup type tables be in scripts in source control. This will make deployment easier.

Buy commercial software or download open source software for the toolset you decided to use with licenses for all the pertinent users.

Buy developer machines that are screaming fast and have two monitors. Buy at least one test user machine that is moaning slow and typical of what the users will have on their desktops.

Train your new developers in how you want things done. If you have a large enough team to have some junior developers, then schedule extra training for them and include the time in your project planning. Monitor juniors very closely for at least three months. Monitor all new employees closely for the first month. Get rid of deadwood and rogue developers as soon as possible.

Determine what needs to be done in what order (the critical path). Do not assign tasks at the end of the critical path until the tasks they depend on are complete.

Create test plans and requirements.

Set up regularly scheduled progress meetings with the clients. They deserve to know what you are doing and what the roadblocks are. Do not fail to tell them when things will be late. If you are three weeks away from a deadline and you already know you will miss it, that deficit will not magically disappear before you have to tell the client. Make sure that the client knows that added requirements means added costs and time and that every added requirement will either have to have other tasks dropped or the deadline will change by the amount of hours in the new tasks. Making this clear from the start will save lots of pain and overtime hours and cost overruns absorbed by your group and not the client.

Set up an environment to performance test, not just the speed of one user, but one where you can test the expected number of simultaneous users. Do not wait to do this testing until the day before you go live.

In project planning, assume QA will find bugs and that they will take time to fix. Do not schedule QA for only one day at the end.

Create test data that is roughly the size you think the database will be. Make all developers test their code against the database of this size. Do not allow developers to only develop against a small database on their personal machines. This is a frequent cause of code that works fine until it hits production.

Plan rewards into the budget. It demotivates people when they work their butts off for months and only managers get bonuses. Also say thank you frequently and in writing.

You may need a project management system or at least set up spreadsheets to track what you need to track. When doing the project planning, assume no more than six hours a day person in your plan. This helps account for the time that will be spent not on the project, such as vacation, sick time, holidays, HR meetings, performance reviews, etc. If you know the project is in a period of high unavailability (say a project that runs form Nov1 - Jan 1 in the US), you may need to make extra allowances for more leave and holiday time. It is not fair to expect that developers will give up their leave and holidays and no one can predict when things such as sick time, jury duty , bereavement time etc will happen. Assume they will happen to your team on this project.

  • I think that test user machine should be "moaning slow", not "screaming slow" ;) very nice list.
    – BlackICE
    Commented Dec 3, 2010 at 16:24
  • @david, I like your suggestion and have changed it in the text.
    – HLGEM
    Commented Dec 3, 2010 at 18:45
  • Great answer - bullet points or section names might help a bit. Commented Dec 6, 2010 at 0:28

Some things I don't see in the question and subsequent answers:

  • Disaster Recovery Plan. How are you backing up the dev boxes, staging, testing etc? Does every dev have what they need to work from home on the occasional snow day? Etc.

  • Training Plan. How many weeks of year of training do your devs need to keep sharp? Is anyone tracking it? (A spreadheet can suffice for most teams.) Have a mechanism for them to report (sending someone an email saying they watched 2 hours of webcasts on "whatever" is probably enough) and for management to plan - eg who should we send to what conference this year.

  • a Tool Position. Is this a "we give you all an MSDN subscription; please don't install anything else on your work machines" kind of place or a "we want your code but we don't care what you use to edit, compile and test it" kind of place. Make and record the decision.

  • as much integrated ALM as you can stand or afford. Usually the reason for the "impedance mismatch", double entry, tool overlap, and swivel chair application integration is that the system grew by bits and pieces. Starting from scratch, you want to show that your people can stay in a single tool throughout the cycle. Not typing code in X, compiling with Y, testing with Z, changing the status of the work item / task with A, reporting their time spent with B, telling the person who was waiting that they can now proceed with C, trying to figure out what to do next with D, guauging overall progress with E, etc.


Negiotiate more man-days.

It is a rare event when people allocate enough initially.

[Later... re-negiotiate even more...]

  • Having the view that more man days must always be negotiated is not something I would recommend, I would prefer to provide accurate and reliable estimates of a job or projects duration. Commented Dec 3, 2010 at 12:49
  • @NimChimpsky There was a discussion on here recently about whether the ability to estimate reliably was a myth in computer projects. Unless the work is very well known and contains no research, then it is intrinsically hard to predict the time. Even if you can predict your own team's schedule - predicting the external factors and delays is next to impossible. So "accurate and reliable" estimates are not something I believe exist as a general.
    – Orbling
    Commented Dec 3, 2010 at 14:28
  • @Orbling they exist where I work. A ftse 250 listed national retailer in the uk. Some projects are late, but not that late, and they are the exception. Commented Dec 3, 2010 at 15:29
  • @NimChimpsky It is possible to get a relatively accurate estimate if you have full control of all deliverables within a project, are not getting blocked by externals and the task at hand involves no research. Providing your budget extends to a thorough analysis before time estimation. In most companies, the budget just is not there to investigate fully before commencement.
    – Orbling
    Commented Dec 3, 2010 at 15:42
  • @orbling Its possible that always requesting more time is purely arbitrary and not at all based on evidence,deliverables, analysis or budget. Commented Dec 3, 2010 at 16:00

Seeing as I've had the most problem with 3rd party libraries and their usage:

  1. Determine the libraries and versions you're going to be using.
  2. Create the process of integrating library updates to your project.
  3. Make sure the developers are all on board the library choices.
  4. Create a beneficial channel for open discussion on technologies being used.

Why? I can't tell you the number of times 3rd party libraries (proprietary) have had henious bugs which sent us back weeks of development time because we had no process for moving up or back down. Or dealing with developers saying "which version did you use? Why did you use functions marked deprecated?"


A large cost to organisations is not assigning budget to security throughout the development lifecycle, this means security usually ends up being in after the fact ineffective, expensive set of activities or controls put in place too late to do much good.

Get security built in from initial project plan, with key milestones, the same as you would with all other aspects of development, and use an iterative process to keep security guidance up to date. Final signoff from security should ten be a no-surprises check that all security controls were implemented as per design.

Otherwise you'll end up running security after implementation - where it could cost 8 - 10 times as much (figures from Gartner, IBM and others), will upset people as functionality is likely to be impacted and it may be too late to prevent exploitation and damage.

  • I'm curious, this should be part of project setup checklist? I'd put it in as part of software development, but I don't know about project setup. I'd put it in with dev milestones, but I don't think that's what the OP was asking about, I could be wrong.
    – BlackICE
    Commented Dec 3, 2010 at 16:23
  • David - maybe you are right that this level of detail should not be there, but I think there should at least be a line item for security. Better?
    – Rory Alsop
    Commented Dec 3, 2010 at 20:17

1. Take it to the team

Ask the programmers! Really, that's the most important thing. You'll meet lots of resistance if the devs are not directly involved in this change. After all, it's about how they work, not you. It goes without saying, but trying to force methods and tools on people usually backfires horrible.

2. Inspect and adapt

Have the team figure out the best way to work, using your experience to gently help them get on the chosen track. Then, regularly and collaboratively, look back on how you (they) are doing and adapt the process to make it better.