Very often people discuss project/dev. methodologies, type of contracts (fixed price vs. time and material), product release cycles and other aspects of project lifecycle while ignoring or forgetting to ask themselves some very important questions first.
So, let me go over my project checklist and default answers, keeping in mind that the only good answer that always applies is “it all depends”
- Is this project done in small startup or big corporation? This might be more of a rhetorical question, just to get you prepared for different dynamics you might expect when it comes to getting budget for HW, IT support, support from stakeholders etc.. What might be “given” in one company can sound as a bridge too far in the other one. Be prepared before you start project to check all of these and if required – work on your networking.
- Is this project about building a product or is this one-off customer project (CDE)? Goals are not necessarily the same for both. If we talk about CDE projects, it is important to satisfy a customer who pays the bill (here we either go XP way or implement everything to the letter), while if you want to make a product that sells over years, I would argue that PO role is much more than just a customer facing person. That might as well answer the question in case you do outsourcing, whether you should be in favor of fixed price or time and material contracts.
- Is this project part of the bigger solution or not? You can afford to do agile project planning by selecting features from the backlog for the next iteration one iteration upfront only if you are the only customer of that project. Period. Here I am not making distinction between company that is the customer of that product, or the product that has only one customer. In case that your product is part of the bigger solution, you need to build a skeleton plan (see story maps and similar techniques) and revisit dependencies over the project lifecycle. “Famous” Gantt charts can help you too – when it comes to drawing dependencies with other modules, products and expected milestones – which you need to communicate to outside world anyway. Be ready to add communication and planing overhead into your project. And to make it clear, I am not saying that in that case you should give up on agile development – just that you need to add real project management role to your scrum master role or ask someone else to do that part for you.
- Is this product going to be deployed in the cloud (server side on the web) or it is going to be installed at the customer premises? If your product is hosted on the web, maintenance cost is minimal and release cycles can be very short. If you are making B2B software that ships to customers behind firewall that expect fixes up to 3 years from the date the product is released, any release cycle shorter than 6 months is suicidal. Nevertheless, continuous integration and unit/automation testing should always take place, no excuse there.
- Is this product made for space program, military, medical institution, finance, large business or end consumers?Level of regulations, required documentation, tools that are used, coding languages, procedures, is something that you or your team can’t always decide on their own.
- Is this single or multi-site development? If this is your first multi-site project, grab books from Crag Larman or Alistair Cockburn that talk about it and read them twice. After that, be ready for some traveling.
- Is your team made of motivated and senior developers or not? If you have bunch of young motivated guys, you will succeed – in the next release, providing you are still around and people are still motivated after the first one. Take time to train people, be aware not to do too much micromanagement and keep the good spirit in the team. If you have bunch of non-motivated juniors – run away. If you have non-motivated seniors, you have to earn your money. And finally, if you have a great team, you should not worry, you will even have some time to read and write some boring blogs.