In this issue, we have looked in detail at agile ways of working. And we have also explored our own company history, which began 18 years ago as a start-up. Are the two things connected at all? You'd better believe it! Because, from our own experience, we know: the success of a start-up lies in its agility.
The manageable team structure of a start-up allows for extremely fast learning and response times, as requirements and factors change. The main reason for this is that the effects of decisions taken - good or bad - are reported back directly to the team. There are no decision-making and feedback cascades involving people who only half-understand the problem, are not involved in the issues, or who are in fact setting different priorities. That saves time and vitality for those involved in the actions, and is very likely to improve the quality of the decisions.
As a company grows, this speed and the direct line to the market is often lost for structural reasons. It's a dilemma that all companies above a certain size are faced with. Including us. Agile working is therefore an issue at VISUS too. And the benefits of small, highly-responsive teams that are quick to respond can be implemented within bigger structures too. If people have the trust to surrender responsibility to others and to create an environment that favors such structures.
What's needed for that are interdisciplinary teams of employees whose skills complement rather than duplicate one another; a definable task area within the enterprise, with a clear purpose that is measurable as far as possible; and team members who communicate with one another and learn both from one another and from the feedback on their decision. You could say that the challenge is to coordinate a lot of small start-ups within the enterprise, able to measure themselves by their success.
And I'd like to take one example to illustrate that such an approach can also create value-added in healthcare facilities, too. At present, it is not uncommon for the specifications for an IT installation to have been superseded by the time the tender goes out. A large part of the reason for that is that the conventional processes for reaching a consensus are too protracted. By the time the preferences from users and/or IT have passed through all in-house instances from bottom to top and back again, a lot of water has flown under the bridge and numerous (lazy) compromises have been agreed. Wouldn't it be more sensible to form small project teams comprising the user, IT specialist, purchaser and controller, that concern themselves exclusively with all IT change processes? Teams that learn continuously how medical and business value-added chains operate through IT processes? That work continuously on optimizing the value-added chains, with demonstrable results? And, above all, teams that have the necessary time to be able to design the change processes jointly, committing their full energy. That, in turn, would massively boost quality of implementation, and ultimately user satisfaction. And who could want for more than that?
Are you interested in founding a start-up?
VISUS Managing Director Technology