By: Shami Dugal
Leonard Bernstein said that “The right music played by the right instruments at the right time in the right combination: that’s good Orchestration.”
Orchestration is an integral part of composing music. It starts with a vision of the music that will be played. The lead in, which instruments, when they should be played, which of those will harmonize, transition, the ending – flourish or ebb away…..
A good composer must understand what an instrument can and cannot do. A flute can’t play low notes like a tuba, and a clarinet does not sound like a guitar. It’s all about harmonizing and creating the right sound where every instrument and player performs its precise role.
Yes, there are virtuosos that raise the quality of the performance. But, their skill and qualities cannot remove the deficiencies of the players and instruments. They are facilitators and mentors who can raise the level of a performance by getting the most and best out of the individuals.
In my view, “It is the delivery of work in response to a need, using the right people, with the right skills, managed in the right way, to achieve superior results: that’s good Project Orchestration.”
Between 1960 and 1990, the world of Information Technology was relatively slow paced. Projects were carried out using traditional Waterfall System Development Lifecycle methodologies where project phases were mostly sequential and a medium size project took four to six people about six to twelve months to complete.
The hardware, software, languages and case tools normally came from a single source. It was early in the days of electronic data processing, and there was limited talent and the learning curve for products and methodologies was long. The ship took time to navigate and maneuver. The world was not agile. Traditional Project Management approaches were sufficient.
The world used to rely on single source companies for products such as IBM, Digital and HP that owned the complete solution set, drove standards committees, and dictated platforms for third party products. Although it appeared that there were many third party product companies besides these on the horizon, the truth was that large companies still owned the turf and wrote the rules.
From 1980 onwards, business took advantage of mid-range computers and began departmental computing. Adventurous business groups thumbed their noses at IT Departments and went their own way with Lotus, Excel, Clipper, FoxPro, Focus and the like. These products were used to tap into enterprise data and provided business functions such as finance and marketing with autonomy in building solutions with their own budgets. However, these ad hoc departmental solutions were difficult to maintain and created chaos when they were moved over to MIS departments for support.
In the 80’s, Novell, Microsoft and other companies were coming of age and creating their own territories and solution niches. Telecommunications was becoming an important player and clients were learning to cherry pick products and service providers.
New technologies and products brought interoperability issues. Consequently, understanding disparate and heterogeneous technologies and knowing how to make them work together became critical.
Many executives went with promises of delivery based on slick marketing guarantees and dubious references. Out with formality, process and traditional project management; in with rapid delivery and quick hits. The results were not positive. A fledgling IT industry that had struggled to gain respectability was reeling again from unfinished projects and a budget drain.
When projects fail, organizations look for scapegoats. However, it is not prudent for executives to blow the whistle on their choice of failed vendors, who escape unscathed. This secret handshake allowed failure to fester to the point that executives and vendors played musical chairs between companies because blaming each other would make both culpable.
With the new Millennium, and hard lessons learned, it is apparent that business is tired of poor solutions and non-delivery and has come to the conclusion that it is either not willing to spend money until it has assurance of success or it is going to inflict punitive punishment on those that are incapable of delivering success.
So, it’s back to formality, methodologies, references, quality, accountability….but in a faster paced life. It gave us experienced folks new life that had stayed the course, remained “technology young” and believed the theatre of the absurd could not last forever.
Project Management has fundamentally changed. It now takes a project manager with an understanding of varied technologies and tools to formulate and explain potential options, scenarios and solutions to clients and then to manage projects that utilize the tools and individuals with matching talents.
Out with traditional Project Management. Born, the Maestro, and Project Orchestration.
Shami Dugal has authored system lifecycle development methodologies for two Canadian chartered banks and delivered lectures on systems analysis and design at Ryerson University, Toronto, Canada. He has mentored projects for thirty years in many industries in the public and private sectors. He is a member of ASPA and on the SHHSA Board. He has Bachelor’s degree in Operations Research from University of Waterloo (Canada) and an MPA from Drake University (Des Moines, Iowa). He can be reached at email@example.com.