Healthy project management

My recommendations how to make your projects healthy and teams happy:

1. Keep the balance between time and scope of each project, cut the scope first.
2. Use clear terminology.
3. Use commodity technologies whenever you can.
4. Keep the balance of expertise in a team.
5. Run technology projects to increase your capabilities.
6. Repeat experience a few times before generalization.

The balance between time and scope

With every project you should:

1. Define the business value or technical capability to be delivered — the project goal.
2. Split the project into smaller ones (research, achieve technical capability, delivery of something) if needed.

Repeat the steps mentioned above until each planned sub-project is within a reasonable time and budget.

Why keeping the reasonable scope is so important:

1. Anything is easier to understand for a new team member. This means the expertise is scalable.
2. It's easier to communicate decisions because of team size. It leads to more effective process.
3. When the project goal is in the line of sight, it's easier to find the right trade-offs.

In any vague situation cut the project scope (save time).

In large organizations, there might be tendencies to bloat the scope to sell the projects. Frequently, when things go wrong managers just cut the time for architecture, but not the project ambitions.

Healthy organizations stop a project that's going to fail, overview results and mistakes, then start another one (smaller organizations are more likely to choose this way).

Clear terminology

All the project stakeholders (manager, technical team, business people) should share the same business concepts. It's often undervalued.

The idea of the popular book "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans (ISBN-13: 978-0321125217, ISBN-10: 0321125215) is to divide a large area into bounded contexts, within which people use an ubiquitous (equally understood) language. So, language and scope are related — to manage both you have to balance the scope, but also to work on the understanding.

If shared understanding happens to be unattainable, it usually means:

1. Too big scope.
2. No will to think in the stakeholders.
3. Disrespect and incompetence disguised by time-saving.

Commodity technologies

With any IT project you manage unknowns and blockers. Why add ones? With a weird technology you might have to make compromises that you normally wouldn't.

Usually, the use of unpopular technology happens when:

1. Manager is relying on his / her own expertise only (what about team?).
2. Manager is convinced by some vendor.

The only good reason to use non-commodity technology is — it has proved its perfect suitability for the task at hand. So take care about the proof and notice — the proof of the pudding is in the eating.

The balance of expertise in a team

In agile, having the universal team members and continuous learning from each other inside of the team is a vital part. This ensures the expertise balance.

If you have dedicated roles (analyst, architect, developer, QA engineer) you should think about different levels inside of each one:

• lead - a person responsible for final decisions (must possess high expertise by definition).
• seniors - people with high expertise. It's better to use them for challenging tasks.
• middles - the people that are making 40-90% of regular work.
• juniors - the people that are just started their way in the profession. They save money by doing simple tasks (20%-70% of work).

In a healthy team there should be a moderate rotation and continuous growth from juniors to seniors. This guarantees motivation, constant attention to problems and expertise handover.

More importantly, the role starts with a lead. The lead is a strong senior who is able to control his responsibility area when it comes to the commits (in the direct and figurative sense) of other project participants. If you put a junior in the leading position the consequences will be:

1. He / she will be growing 2-3 times slower than could with a good lead.
2. At first, he / she will not really be able to control anything, but can block the work with defensive behaviour.

Don't think that by recruiting juniors you save something if they leave you without reaching seniority.

Running technology projects

The technology projects (research, technology migrations and so on) are necessary:

1. To build technical capabilities itself.
2. To acquire modern architecture practices.
3. To keep the balance of expertise in your team.
4. To keep people energized and committed to work.

That's why you aren't going to be a growing company without technology projects.

You don't have to formally "squeeze the result" from technological projects, focusing only on the 1st goal. Without training, mistakes and their correction (take time for it), there is no good architecture and, therefore, there's no future for the technological capability you create.

Repeating experience

Too early generalization is a form of overengineering.

First, collect cases. Think of a generalized solution challenging its design against the scenarios that will be discovered. Take time for it. Otherwise, chances are pretty high you'll have to break the architecture many times.

Second, modularise your solution and avoid tight coupling.