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 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.
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.
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.
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:
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.
It is different for organization to organization, what is prioritised in a project. However, most would agree on the following key points:
With the above, you are not guaranteed - but have taken some very important steps - to avoid the bigger IT disasters.
The fashion industry is in deep trouble. Brands abuse scarce resources, they overproduce to create more consumption and growth, and have a huge credibility problem with consumers who require sustainable action. In others words: It is time for a new model. View the presentation on circular e-commerce from Umbraco Codegarden 2019.
Thursday evening the best e-commerce case was celebrated at the yearly FDIH award show in Øksnehallen, Copenhagen. Compent was nominated together with Shamballa Jewels in the category “Best e-commerce case 2019” for Shamballa Jewels Global Sales Platform. We are super proud to walk away with the first price being nominated among other strong e-commerce cases.
Every year the best Umbraco projects are elected at the Umbraco Codegarden conference and a total of 10 awards in various categories are awarded among several hundred projects. This year Compent won in the category Best New Tech with the Shamballa Jewels In-store Jewelry Designer.
We have just upgraded our internal baseline to Headless / .NET Core and will describe the main points for why you should consider Headless architecture for your next Umbraco project. A Headless CMS project means that the classic dependency between the CMS platform and the presentation layer have been removed. This means in practice that front-end is physically separate from the back-end, and you can therefore develop the presentation layer independently of the CMS platform version.
Something that characterizes many of the projects that we undertake for our customers is that they start from an existing project that has gone wrong. When a project has gone wrong, the reason may be misunderstandings between the former supplier and the customer about how the project was to turn out, that internal members of staff are not qualified in the field to which the project belongs, inadequate or poor technical implementation or perhaps simply deficient routines. It can be hard to tell if the problems are caused by one thing or the other without doing a thorough analysis, but if you go through the ten points below, it might be easier to obtain an overview of how problems may occur.
Many intranets are developed on Umbraco, but no standard platform has existed for a long time that you have been able to use from our.umbraco. With uIntra it has become easier to develop an intranet on Umbraco without having to start from scratch. A short while ago we placed version 0.2.3.7 on our.umbraco for free download. Among the new functions are groups, emoticons and comments on articles plus many small updates.
Umbraco is what you might call a classic system for web publication and presentation. For this reason it is often not associated with intranet use where functions such as decentralised administration, work group functionality, member management, document management and rights-based searching are among the most critical features. However, this does not mean that Umbraco cannot be used for intranets simply because all features do not appear out of the box in Umbraco. Whether Umbraco is the best choice for intranets therefore depends on which functional needs you have concerning your intranet.