Those who have worked on projects know first-hand that feeling of indescribable happiness of releasing a live project . The communication from the leader confirming that the project has come into operation generates great satisfaction and at the same time great fear, given that behind those three lines of the email, there was a schedule, design, expectation, knowledge of the work team, unforeseen events, action plans to solve problems, changes in resources, discussions, new interlocutors, late nights, decision making, in short, the list is endless.
Technology projects in particular have certain additional components that add much more “excitement” to being able to have a project not only live, but stabilized.
Stages of a live output
- Preliminary stage
The first ingredient is that when the need to start a project arises, the promoter assumes mental maps where the entire need is clear and the design phase ends without starting. Most of the time they start from diagrams or sketches that lack any level of detail.
Most of the time the start of the technology project has nothing to do with technology and different needs arise in terms of reforming the processes and evaluating the suitability of the people on the team who execute the actions that will be impacted by the implementation. of the technological tool.
In this preliminary stage, the first frictions appear given that the times of need are already delayed because it had not been possible to convince the sponsors to invest in a technology solution (here are some tips for selling a technology project within the technology companies successful way). Time commitment is an extremely delicate issue that generates a lot of frustration since it is normal to assume times without being clear about the need or the level of effort and are based on project practices other than technology that are not comparable.
- Design stage
Assuming that this preliminary stage was passed and the decision was made to allocate resources for the execution of the project, the functional design stage begins. In this phase, all these high-level ideas must be captured in a detailed document that, later, will be the input so that a technological development team can materialize the need .
This document turns out to be a headache for functional managers since by uniting the team that executes the task that will be digitized or automated every day, there are many edges and different criteria are executed since it ultimately depends on people.
Additionally, there are cases that, despite being the exception, are treated as a primary need to be implemented that lead to the development of highly complex logics without the calculation of a cost-benefit measure. This process takes many iterations, is very exhausting and is usually the first disappointment of the project that must be controlled given that the original estimated times were already exceeded attending a design stage that, since approval, had to be 100% completed.
- Technical review stage
After this comes a technical review stage to ground the functional need into logic that can be achieved, most of the time the functional needs are “a letter to the child God” in which the materialization is quite complex and requires much higher resources. than initially estimated due to a high-level sketch that did not have the necessary detail.
An additional component that adds complexity to technological projects is that the integration of different technological tools is functionally imagined. This, despite being feasible , most of the time involves coordination of different interlocutors, technological providers with different ANS, work, priorities, is a “tower of babel ” that requires the best of controls and rigor on the part of the person responsible for the project as a whole.
The problem of this stage is not only getting the technical teams to agree, but also being able to transmit to the functional team the technology restrictions or the impacts of the project to execute certain functionality. This stage generates a lot of frustration for the functional team given that the premise of the original project was to fulfill a functional need and not fulfill the need taking into account the technical restrictions that should not exist.
- Development execution stage
Once all the stages have been passed, there comes a landing of the times and a detailed schedule to begin the execution of the developments; A relevant issue is that the previous stages already had a delay with respect to what was originally planned and the availability of resources may have changed abruptly and the first thing in response to this release is a phase of resource programming and pertinent release to attend to the project that , normally, is not considered in the original work scenario.
Normally, the deliverables of technology projects are binary, there is no way to show progress due to the number of dependent, linked and impacted technological components, it is not possible to show part of the flow or the tool without an integration. This restriction is quite difficult to explain and transmit to the functional team , since projects in other areas can be seen step by step and even make corrections to what is being built.
In technology, what is designed is developed, what is designed is tested, and what is designed is delivered to the client. Normally, in this delivery, the client tries to involve new actors who will be impacted by the output of the project in order to carry out adequate change management. Here new needs arise, different perspectives, other casuistries that, by not being considered in the original design, once again impact the defined schedule . The option of closing oneself to changes in this stage of first contact with the users who are going to operate the tool can generate discomfort and frictions that greatly harm the acceptance of the project.
A good action to control this issue is to carry out a survey of new requirements on two fronts: those that are totally necessary to start the project, “stopper”, and those that are desirable, but are not necessary and their implementation would improve the experience, “nice to have”. A relevant issue at this point is to be quite clear with the defined scope and an expectation in time and resources to be able to address 100% of the needs.
- Testing stage
One of the most important stages of the entire project is to execute functional user tests and give formal approval that what has been developed corresponds to what was agreed upon in the needs. Here impediments arise since the team prepared for this does not have it as a priority, since they must continue to attend to the operation with current tools. It is quite important, although it is difficult most of the time, to allocate quality time for the execution of complete tests to control as much as possible the incidents that may arise in the operation of the project.
- Live output stage
All of the above materializes with the deployment of the functionalities and getting productive. For this, you must have a lot of order and discipline to be able to compile absolutely the entire history of the project’s journey up to this point. Any forgetfulness can generate great dissatisfaction or must be controlled carefully. speed and proactivity. After that comes a whole stabilization stage that must have first-line attention and be able to generate as little noise as possible since parallel to the operation of the project, change management actions are being generated for positive reception and overcoming entry barriers.
As you can see, behind the live technology projects, there is a whole world behind the scenes!
