Cookie Cutters For Projects

Background

When you’re starting work on a new project or organizing a team to accomplish a goal, there’s often a foundation that needs to be established:

  • How is your team structured?
  • What software should we use to help us?
  • How do we set goals?
  • How do we measure our progress
  • … the list goes on.

It’s a common challenge that’s met by anyone organizing a team or setting off to work on something. So do you copy what worked for someone else by using a cookie cutter approach, or do you wing it and see what happens? My approach when faced with two extremes is usually to aim somewhere in the middle.

 

Cookie Cutters

Being a copy-cat and using cookie cutters has some benefits. If something worked for some all-star teams at big successful companies, then why re-invent the wheel? They’ve proven that they have a process that works!

Look at a successful company that’s the same size as yours. Look at a team that’s completed a project that has a lot of parallels to what you’re going to be working on. How did they structure their team? Did they split off into smaller sub teams? Did they have daily meetings to discuss progress? Weekly? Monthly? Are they using some sort of software to assist them in their work? Maybe it’s a ticket tracking software, or some CRM to aid with customer interaction. If it worked for them, why wouldn’t it work for you?

The answer to that is because you aren’t them, you’re not working on the same project, and despite all the parallels you might see, your environment is different.

 

From Scratch

Okay okay… So if we can’t copy people, then let’s just do it all from scratch. Start your project tomorrow by holding a meeting and seeing who wants to work on what. Let people just start tackling parts of the project. Have someone create some software that will help you in accomplishing your goal (after all, you don’t want to copy someone else and use some well-established software). And now that you’ve all set off on working on parts of the project, you should probably just meet whenever you need to. Probably not best to schedule anything, because you don’t even know if you need to meet!

So, that sounds pretty sketchy, right? Clearly doing everything from scratch doesn’t seem ideal… Why re-invent the wheel on things that have been proven to work? Where’s the happy medium?

 

The Happy Medium

The truth is there are aspects to tackling a challenge with a team that have been proven to work. There are processes out there that teams have used successfully, software that has improved team efficiency, and strategies for gauging progress that have been used effectively. So when do you copy and when do you work from scratch?

My personal recommendation is to evaluate your options from the start. Look at what other successful companies are doing. Do they use a waterfall approach to developing products, or are they agile? Are they using particular software products for tracking progress, managing projects, interacting with customers, and/or automating processes? Make a list of those too. How often do they meet with other team members? Why are they meeting at those intervals? What are the pros and cons?

After you come up with your options, start gauging how they might apply to you. Your customer requirements are set in stone for your enormous project? Maybe a waterfall approach is better than being agile. Everyone on your team has success using Git and bad experiences using subversion for their source code… So maybe you start with that. Maybe tasks are changing pretty frequently and it’d be helpful to have frequent updates from team members, so you meet briefly every day for updates. Look at your options and think of why certain ones might be good for you.

Start with something. Try it out. There’s no guarantee you’re going to be right the first time you try things out. Actually, it’s likely you’ll do it wrong. But so what? Find out what works. Find out what doesn’t. Then figure out why something didn’t work, and swap that process for something else. Swap that software for something that fits your needs better. Change what doesn’t work and you’ll converge to a rock solid foundation. But don’t fix what isn’t broken. If your daily meetings have been working well for everyone, then why bother arbitrarily switching them to weekly? If it works, then use it.

 

Summary

Regardless of your approach to getting your challenge completed, I think one thing is important: Have flexibility in your foundation until you find what works. Don’t use certain things because other people say to. Use what you think might work best after you’ve evaluated your options, and then once you’ve had it in place for some time, change what doesn’t work. Use the cookie cutters as a source of information and inspiration for why you might want to try something, but don’t let your entire foundation be built from one big cookie cutter. Use lots of little cookie cutters to make your foundation for overcoming your challenge the best it can be for your team and not someone else’s.

author avatar
Nick Cosentino Principal Software Engineering Manager
Principal Software Engineering Manager at Microsoft. Views are my own.

Leave a Reply