Why you don't need an onsite .NET / Umbraco consultant

We sometimes receive queries on an on-site .NET / Umbraco consultant to solve development tasks on site. The use of IT consultants is a big market and in many industries there is a consensus that this can be a good way to solve tasks that are beyond the primary competencies of the company or as a way to reach the goal faster in a project that have high priority. The model with on-site consultants is probably the right one if you have a concrete challenge with its Navision or SAP setup, but the use of short-term on-site consultants is a risky affair if you have a longer term strategy and have a outright development project.

The challenge with IT resources

The number of developer man hours is actually not the most important or proportionate to having a good IT solution.
It is rather how the process of development has been and what initiatives that have been taken to ensure consistency and a long-term plan that can be further developed. Different scenarios for how an IT set up can look. can be seen below:

IT project with one specific developer. This is the fastest way to get started - but also the most dangerous potentially. With a Full Stack developer doing everything, there will be quick progress on the project, but there is a great danger that the architecture is not possible or too complicated to extend and can not be taken over by others. The vast majority of developers develop based on their own point of view, often work under pressure and rarely have time to document or verify what has been made. Therefore to the project owner, this poses as a potentially ticking bomb in the event of job change, illness, maternity leave - and even the project becoming too big, can be a very large burden for the one person sitting with the whole solution that can easily lead to stress and inexpedient decisions. Using an all-round Full Stack developer is a dangerous cocktail because collecting all front-end, back-end, installation and testing responsibilities in one place, easily can lead to regrettable situations.
 
IT project with two or more permanent developers. This is the right way to go. But typically this requires a big investment, as you need a permanent development team and often a development project will not have the resources to sustain such a task as it will be too short-term. In principle, however, it may work, but there is also a great risk that the environment around two or three developers becomes too tight and closed off from outside inputs. In which they become a small internal department, which it can be difficult to attract the right development profiles to as the freedom becomes restricted in an already small environment, which leads to too little inspiration from the outside.

Ad-hoc addition of external consultants to an existing project. This may make sense if there are specific areas where there are no internal competencies to solve the task. But in the same sense that 9 women can not give birth to one child in one month, it's not a solution to chose in order to finish the project faster. The increase in resources is not necessarily proportional to the quality of the work being carried out, and under the wrong prerequisites, it can even have the opposite effect.
 
Adding external consultants with fixed allocation. With this scenario you can have an external setup that can contribute to your own organization. This can typically be in collaboration with your own IT department or outsourcing of development tasks outside the organization's primary focus area. By involving consultants from a major development house where there is certification, teaching and a wide professional IT environment, it ensures that there is an external setup that can survive employee replacement, changing technology trends and changes in the organization. However, it is important not to be tempted to choose just one fulltime external consultant. It's better to have two half-time developers than to put all the tasks on a person- although overhead can be a bit bigger.
 

Resource setup however is only a prerequisite for a good start. If the environment and processes are not in place, even the most talented consultants may fail in relation to expectations. So getting a successful IT project is not just about getting the right developers, but just as much about having the right environment in which the good results can be created. The best part is to have a structured and agile setup where you can eliminate wrong directions quickly (and be fault tolerant) and ensure long-term continuous progress.

The trouble with programmers is that you can never tell what a programmer is doing until it’s too late.

Seymour Cray

Determine the goals through one project owner

Often, IT projects projects suffers from either none or too many project owners. In order to prioritize business goals and translate this into development tasks in the right order, one person is required to act as project owner while the project is running. It is important that there is a key person who prioritizes tasks and can keep up business requirements so that all questions can be answered without any doubts or delays.
 
The fact that the project owner is actually part of the organization is a clear advantage, but a proxy project owner can be used as well if there isn't resources for this internally.
However the project owner is not the only important person for a successful project. So in order to avoid misunderstandings about areas of responsibility and conflicting interests, it should always be described in the start-up phase who is responsible for what and what roles they should fulfill. This also makes it easier to analyze what's wrong if problems should arise.

Be agile in order to track progress quickly

Being agile should not be confused with just adding resources as needed or thinking short-term. It is rather a question of agitating pragmatically and testing what's done against reality as often as possible. There should be a structured process on how tasks are described (user stories, acceptance criteria, etc.) and there should be one primary project owner (see previous section) and a defined roadmap that is understandable to all developers, testers, project managers and others participating.
 
By far the best method is Kanban, Scrumban or Scrum with a digital platform support in the form of Atlassian JIRA or equivalent, which is then supported by daily or weekly priority meetings (tips, although Kanban is often illustrated with yellow stickers on a bulletin board, this is not a viable way to go).
 
In addition to this basic setup of process, it is also necessary to have a supported technology with, for example, GIT and continuous integration (TeamCity, Jenkins, Octopus or equivalent) so everything that is made is traceable and can be released or rolled back if necessary.
 
To quote LinkedIn founder Reid Hoffman's quote "If You're Not Embarrassed By The First Version Of Your Product, You’ve Launched Too Late" This is particularly important in a world with a very hot IT job market, and you can never know with certainty that everyone on the project is still there in 2 months. In order to ensure its architecture, one should therefore utilize short development loops and ensure that it is released continuously and that experience is learned and passed from each loop. Every time the release date is postponed, the chance of something being built on incorrect assumptions increases and the risk of releasing it increases.

If You're Not Embarrassed By The First Version Of Your Product, You’ve Launched Too Late.

Reid Hoffman, LinkedIn founder

Retrospective analysis

What distinguishes the most successful development teams from other less successful is typically that the successful ones are able to optimize their own processes and constantly make fewer mistakes and become more effective. This is not something that happens by itself, it requires meta reflection on the process and the will to optimize and change its own workflows.
It is part of the agile model to make retrospective review and optimize the process. The simple questions are here:
 

  • What has not gone so well,
  • What can be improved
  • And last but not least
    What will we prioritize to improve for next time.

It goes without saying that in this setup there is no room for short-term employee on-site consultants. They will typically be blamed for everything that can and will go wrong and will thus not be equal in the team and could not help to develop the process model that must not be underestimated.

Summary

It is different for organization to organization, what is prioritised in a project. However, most would agree on the following key points:

  • Have a set up with internal and external consultants that are not fragile and personally dependent.
  • Set clear goals and let these be followed to the door of a project owner or proxy project owner.
  • Work agile and publish software as often as possible.
  • Learn from processes by holding retrospective meetings often.

With the above, you are not guaranteed - but have taken some very important steps - to avoid the bigger IT disasters.

Other blog posting
linkedin twitter facebook arrow-left arrow-right