Project Orchestration: Project Management for the Internet Age (Part II)

By: Shami Dugal

Project Orchestration

A project today reminds me of fractal geometry. Why? In a fractal, the whole picture consists of similar parts, as you can see in this picture.

The same self-similar concept applies to a project which is recursively composed of phases, a phase of activities and an activity of tasks. Completing a job at the lowest level allows the higher group of work to be completed.

However, while the pattern of work repeats, each of the technical work steps can be complex because of disparate technologies and skill sets needed to undertake them. A business framework can be equally complex, with global operations working at the speed of telecommunications. For a project manager, devising, developing and managing solutions with these parameters can be very challenging.

While the framework of a project looks complex and somewhat incomprehensible, we have to make sense of it in a way so that it can be explained. We can begin with the fact that projects can be discussed in terms of phases, guidelines, standards and techniques.

People often confuse one term with the other, or try to use one of them as an entire approach for managing a project. It is instructive to review the definition of each of these terms and how it fits into a project framework.

A project consists of several phases. There is clearly a Definition phase where the problem or initiative is explained. The next logical phase is Delivery where the solution is devised and plans are developed for its construction and delivery. The last phase is Deployment which involves the implementation of the solution. While this may appear to be perhaps too simple a view, it is important to keep it simple at this point as there are additional terms to be discussed.

One can envisage a set of guidelines for proceeding through the three phases and their internal sub-phases and steps depending on the nature of the project. Guidelines can then be defined as the doctrine that facilitates the execution of tasks and construction of deliverables. Standards represent templates for end-products, deliverables and milestones. Techniques consist of approaches for conducting tasks based on defined methods.

When mainframes rules the world, I was tasked by a large chartered bank to develop a methodology that would enable them to deliver major projects on time and within budget. The methodology was developed over a period of a year, implemented across the bank and tested on small and large projects. The results were very successful in terms of timely and cost-effective delivery of work. We trained not only the information technology staff but also spent considerable time with the business partners to explain the benefits of the new methodology.

Why was it successful? The reasons are as follows:

First, business and IT arrived at a “contract” that was based on documented user requirements (what do you want) and a design specification (if I provide you with this solution, do you agree that it will meet your needs?).
Secondly, the schedule, cost and delivery timetable were based on this “contract.” Any prior estimates were only a best guess and were obsoleted by this. The triangle of requirements, resources and time were strictly observed by the business and IT. No compromises.
Thirdly, scope was managed and adjustments to resources, cost and schedule were made accordingly.
Lastly, project results were reviewed and the methodology was updated as needed.

This methodology consisted of phases, guidelines, standards and techniques. All staff were required to follow it. The approach was adjusted to the project within an approved latitude. The project work was not forced into the methodology straight jacket.

So, why do we have statistics that a very large number of IT projects fail, never see the light of day? Those that survive are not necessarily done well, and are often perceived by the business partners as not good value for money.

One or more of the following reasons may resonate with your own experience:

Lack of a committed executive sponsor for the project
Mandated requirements, timeframes, cost, technology that breaks the triangle
IT is considered an expense, a bad one at that
Lack of respect for IT executives, with no place at the executive table
Poor documentation of requirements, lack of a “contract” with business partners
Selection of technologies that are not mature
Use of disparate technologies that do not work together
Continued investment in technologies past their time
Failure to bite the bullet and move forward

I can go on, but you get the point. Don’t shoot me because I am a messenger with a dose of reality. After more than thirty years in the business, managing two companies and dealing successfully with many small and large projects, I should have a clue.

When projects fail, management typically engages consultants who propose methodologies, education for staff, a PMO office and other such types of band-aid solutions. They typically do not want to tell their clients that the real problem is the organizational culture. The fix starts at the top. They fear that this type of recommendation will result in a loss of business.

Some companies will propose a technique du jour such as Agile development. Agile assumes that you have a set of baseline requirements which will be developed incrementally. It assumes an architecture in place. It should be adopted by organizations that are sophisticated enough to deal with it. You cannot run if you have not learned to walk.

Life in the IT organization used to be difficult enough forty years ago. It was early in the business and we were beginning to gain an understanding of how to do our jobs in this discipline. Since then, technology has advanced at a pace that has distanced itself from the players who have not developed management and technical sophistication to keep up with it.

When technical solutions are considered, some questions need to be raised – what generation of technology is it being built for? Desktop, tablet, smart phone, all of them? Who are the users and what instruments are they likely to use? What infrastructure is needed to support the products?

When these complex issues are added to the scope of a project, risks and staff skill issues begin escalating. Remember, many of us are still working on an acceptable way to document requirements and develop a “contract” with business partners. I suggest that while we are in a rush to capture the market from our competition and create snazzy applications, we should take a moment to add some formality to the process. Why? If we do not, however cool the end-product of the project might be, it may not meet business needs.

Between the business and technology functions, we are discussing a zero sum game. The question raised by the business (I would like this) and the answer by technology (it can be delivered at this cost and time) must be balanced. Without trust and mutual respect in a work like manner on equal footing, the result will be a disaster. We will not have to look far for examples.

Project orchestration is common sense, but it is not so common! There is a great deal of skill and experience required to achieve success. Business management that recognize this truth and develop a symbiotic relationship with the technology group will realize dividends. Those that do not will face a revolving door of changing staff.

________________________________________________________________

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 protected].