Top 10 tech-leading tips for an Episerver project

If your Episerver project will be successful or not will usually be determined before any code is written in the project. Here are a few thoughts on how to make your project succeed before even that first compile. Preparation and setting up good team work and communication is key. Don't worry about the technical parts.
Should be something there for both tech leads and for those ordering Episerver projects. Focusing on soft skills and planning this time, so if you are looking for code samples, check my other posts like this one. This is the distilled version of about 10 hours of workshops I've been holding for tech leads this autumn. Feel free to ping me on twitter @danielovaska if you want to continue discussing :)

"A bad general goes to battle and hope to win. A great general goes to battle and knows he has already won." - Sun Tsus Art of war

1. Set prioritized goals and target groups

Why are you doing this project in the first place? What are your overall goals and target groups. Goals that can be measured are great. Be sure to prioritize both goals and target groups. This will help you later on. You might think this is obvious but for instance 71% of the intranets lacked measurable goals in the latest survey from webbserviceawards 2016. It's pretty difficult to succeed if you don't know with what. If your customer doesn't have this information yet, suggest starting with a pre-study. Personas can work great. The whole idea is to get multiple stakeholders on the same page and avoid some ugly conflicts later when it gets obvious that everyone can't have everything. If you get this right from the start, you can spend your time implementing a great solution instead. Measuring usage of functionality is also a great tool to help customers prioritize. Put effort on what the users want, not what a single stakeholder want. Think that is their business? Give me back that tech lead badge! Seriously, making the overall solution great IS your main objective and if you need to cuddle with someone to make them drop silly requirements. Do it!

2. Create requirements that leads to these goals

Might sound obvious too. Isn't. The normal requirements list from a client for a complex solution is less informative than my wifes shopping list. I personally like requirements that state a need. User stories are a great start. "As a user I want to be able to purchase products with my Master Card". Just stating the business needs clearly goes pretty far. Just keep number one in mind when you do. Is it truly beneficial to your goals to have 100 different things on your start page? Make it easy to use for your primary goals and target groups. This usually means more difficult to use for the others which is ok. If you truly have multiple target groups that are really really important, consider building two separate systems instead to make them both happy. Fixed priced projects need detailed requirements. Agile projects work best with stated business needs and not too detailed requirements. Just remember:

"It's impossible to create detailed requirements for a complex project"

and don't let project managers handle the requirements part if they have less experience than 5 years in software development. Since they rarely stay that long...either you do it or fail the project.

3.  Pick a methodology that matches your project

To be honest, I've only seen one project ever of the 1000s of tenders I've reviewed that had decent enough detailed requirements for a fixed price project. It was an easy public website without integrations where they had done a great job at a prestudy. That is the only one, mind you. The normal case is that requirements are very vague and ambigous. If you decided to do a fixed price project anyway with bad requirements and then offer the work to the lowest bidder you have already made sure to fail the project. Why? Try advertising and say you will buy the cheapest car with 4 wheels that can drive forward. Think you will be happy with that car? Will the brakes work? Will it be fast? Probably not. An agile approach where you instead buy deliveries of the most priotized functionality every 3 weeks or so is normally the best approach. Agile is becoming the new standard methodology and with good reasons. Waterfall projects fail far too often and the reason is that it's impossible to get the requirements to a decent enough level before the project starts. From there, everything goes downhill, fast. You can still have a fixed price but with flexible requirements where you build core functionality first. For some inspiration in agile development and how to set up organization check out this video and this one. Choose agile over waterfall approach in 99% if you are building something that should last longer than a year. Or you will likely have to build another solution soon because the first one failed.

4. Pick the team

The project rarely needs hands. It needs brains. Dedicated brains, preferably on full time. The fewer the better as long as they together cover skills from design, ux to gui development and architecture. Junior developers / designers works well for simple projects. For complex projects you need senior talented developers/designers that can also help you with requirements. The problem with complex projects are not technical. Worry about competence, availability and talent. Don't worry about hourly rate. A senior talented developer produces 10 times more than a junior developer in a complex project. Do spend time doing interviews if needed. Don't pick people that will just create what you tell them. Pick people that will critically think about what you have missed. Kick people who can't work in a team but think an extra time if you are simply using them in the wrong spot? Just because someone has worked with something for 10 years doesn't mean they can be regarded as senior unfortunately. You also need talent and that is not something you learn. Don't underestimate domain knowledge of the customer organization and business area though. Did some developer/designer do something similar or have worked with the customer before. Get him!

Ditch the tester for more senior developer time if you don't have extreme QA needs like developing online banking etc. Usually not cost efficient now a days. Testers and PMs don't read too much on this site right? :) Automized testing = great for complex parts.

5. Deliver often

This is a cornerstone in agile development but equally important in fixed price projects. A demo every 3 weeks or so is normally a good idea. This will help aligning the project with the business and help finding problems early before they get too big and critical. Build the most important functions first. Build the basic version of the most important function first. Avoid trying to build the perfect function at once. Building a search function to the website might be the most prioritized. That doesn't mean that building faceted results is as well. Split them. Delivering often forces prioritizing and building vertical slices of functionality. Both are keys to success. It also builds trust and relationships to your customers. You will need that at first release.

6. Set up communication and team work

Development team including designer should preferably be in the same room. Avoid communication through issue management system and mail. Meetings face to face is prefered and using issue management only for documenting decisions. The reason projects fail is because people don't talk to eachother. So how do we make them succeed. Put them in the same room. Make them talk and have lunch together. Get them drunk together. Anything to make them talk to eachother without barriers. DO use daily stand ups to get people to help each other out. That applies to the designer too. Creative people can easily be a bit too creative :)

It's all about communication and defining the requirements so it will be both user friendly, cost efficient and work well with the business. For that you will need people from both the business, design and a developer. If only one of these try to do the detailed requirements by themselves, the project will likely fail. Using the requirements process

business requirement => design => developer is usually a bad idea. Can work if you have a team that have worked a long time together.

It should usually be similar to

business requirement <=> design <=> developer in a great project. That is, an idea from a developer should be able to influence the requirements from the top.

Try to focus the business people on "needs" and let team propose a solution / recommendation to not build. Avoid trying to have gate keepers or proxies like a project manager that filters all communication. If you need that you have the wrong developers and designers in the first place. Why? Try playing the whisper game and you'll see. You can't discuss complex issues with someone in between.

7. Avoid politics and prestige and stimulate initiative and innovation

What will a developer do if he doesn't get specific requirements in the middle of the project? If the answer is "nothing until I get detailed requirements" you have likely failed the project already. You need to create an athmosphere where it's ok to fail, where people dare to suggest a solution to a problem even if they don't have a clear specification. You do that normally by assigning a business need to a team, not a detailed solution.

Detailed solutions are like spoon feeding your 10-year old. Might work well for a day or two but isn't really a great idea in the long run. Detailed solutions to a team actually kills innovation and motivation and creates a passive team while introducing bottle necks into the system. What do people do when they lack motivation? They start sitting on their hands and do nothing while waiting for someone to spoon feed them more and in the long run quit because it gets boring. Both cost obscene amount of money for a project since it lowers productivity of the team overall and results in a bad solution where only one point of view was used to come up with a suggested solution. Hence, allow a few mistakes along the way, be liberal with compliments for taking initiative and avoid assigning blame. If something went wrong? Use daily scrum (or at least demos every 3 weeks) to pick up if someone is heading in the wrong direction. 

Fixed price waterfall projects benefit from detailed requirements and suggested solutions though. Still need those three points of view from both design, business and development so make that prestudy great and keep down the scope! 

8. Keep the same people 

Rotating developers and designers cost a lot. I know it doesn't look that way in excel to management but trust me on this one. You lose a lot in both trust towards the customer and productivity. Losing a senior developer in mid project and the project normally fails. Make sure the same resources stay in your projects. Check this before you start. Chain them to a chair if needed. Bribe them with candy also work. Seriously, you need to build a team where people are happy and staying for the whole journey. Otherwise key people will join other greater projects. It's that simple really.

9. Non-functional requirements

Someone needs to consider performance, security, maintainability, efficiency etc. This is often forgotten. If the tech lead doesn't take initiative here, it will normally not get done. Most of these benefit from addressing them early in the project. You normally need to make a case to get funding or sneak one in per sprint...it's for their own good. It's ok to do a little black ops then. :)

10. Tech lead should...lead!

The tech lead is the heart of the project. Don't accept this honorable position if working less than 60% in a project. You won't be able to do a decent job. You are captain of the ship. Your role is not primarily to choose a technical solution but to advise the customer on finding the right solution. You are the expert of how to create a digital solution that matches the business needs. Steer true towards the best solution for the client, which is not necessarily the one they are trying to order. You might think that there are other roles that are better suited for actually leading the project. Unfortunately, you as tech lead are usually the most experienced one around that have been involved in most software projects if you aren't extremely lucky with a project manager. Odds have it you are among the brightest around as well. This means you need to help and guide the customer and project manager whether it's in your role description or not. Don't stand around and hope someone else is steering. Go with your gut feeling and make it a successful project!

Disagree with any of the above? I love people disagreeing with me! Have other top suggestions? That's what comment fields and twitter are for...

Happy tech leading to you all! It's a great role!