Netadmin Content Creator
As one of the leading OSS providers in the Nordics and on the European market, Netadmin Systems have had its good share of well executed OSS projects, but also exceptions from which we have done our bests to learn from the mistakes. Last year, we went back to previous projects in order to summarize some of the most common pitfalls. The results that came out from this are now a natural part in the assessment of all our projects.
Project start - Involving the right people
“Defining responsibilities, mandates and roles is essential for the efficiency in workshops and meetings.”
We encourage that people from different parts of the customer's organization are involved in the requirement process. This gives individual teams and people a sense of participation in this change, a wider perspective of different needs, wishes and requirements, and an early understanding of what is going on.
However, it is important that the route of communication within the customer's organization is clearly defined before the project starts. Defining responsibilities, mandates and roles is essential for the efficiency in workshops and meetings. Your organization can and should have multiple decision makers and stakeholders. This is people that have been assigned to come up with solution to a single problem. This is all fine. What is important at the end is who the decision taker is. This is the single one with mandate and responsible to any further shortcomings concerning his/her decision. The decision taker is the person who can alter activities and commit to resources within the boundaries and budget restrictions provided. The supplier role is to support your organization with all necessary expertise, best practices and documentation and provide recommendations based on the needs and requirements described by the decision makers, but to put it short: you cannot expect the supplier to act as decision taker and prioritize between needs expressed by individual teams or people within your organization.
Expectations and targets
“Just because something can be automated, it does not automatically mean it is a good idea to automate.”
Deploying a new OSS solution can be one of the most important and extensive changes for a telecom operator. The OSS is typically a central system in the IT environment and often connected to multiple other systems in different directions. The expectations among employees and managers are high. Everything can be automated. All exceptions are taken care of. Every single service and technology will now be standardized into this magic box, in which the user just has to click the right button and lean back. An optimistic starting point is of course always good, but it is important to keep focus on value versus complexity throughout the entire project. Just because something can be automated, it does not automatically mean it is a good idea to automate.
Generally, the decision to automate a certain task should be based on either how frequently it occurs or the level of complexity. For example, if a certain service or technology is somewhat time consuming to operate due to complexity but it happens only a few times every month or year, you should really ask yourself if it is worth automating. On the other hand, you could have the simplest service automated because of high volumes. We have previously seen high prioritized items being excluded from the scope after doing some simple math on its value.
Netadmin Systems often recommend a quick launch approach, where first of all high quantity services with fairly low complexity are provided. The aim is to get the customer up running with Netadmin Nine OSS as fast as possible. This will give the customer a chance to get used to the system and learn more about its capabilities and limitations, and most importantly help taking correct decisions in the next phase.
Understanding the design
“In order to determine how a certain sub process or task should be implemented, it is essential to first understand why it is needed at all and what its purpose is.”
Once the main targets and expectations have been set it is time to start designing the solution. We, as a supplier will give you our view and experience on how things should be implemented in the Netadmin Nine OSS. We strive to use as much standard ways as possible to achieve a solution that is maintainable and supportable. In this phase it is important that we have a common language to describe the implementation and that the solution is designed on different abstraction levels. Compare it to building a house. The building drawing tells you about the dimensions of the house, but does not give you any answers on details inside, such as where to install individual power outlets, the size of the hot tub or the color of the walls. This is why the need for different abstraction levels.
One of the common ways used by our customers to describe a process is through BPMN diagrams. BPMN diagrams are a good start, but it is not a very good way to describe functional requirements. In order to fully understand what needs to be done, we need to drill down into each box and describe its purpose and function in the overall process. In order to determine how a certain sub process or task should be implemented, it is essential to first understand why it is needed at all and what its purpose is. Quite often, this information is kept in heads of individual people or simply explained as the way it has always been. The why-what-how approach is today central in all our projects.
A real-life example where we had to look at the bigger picture was a customer that described a complex provisioning of CPE devices. There was no good explanation for why it had to be this way. After some investigation we found out that the reason for the rather complex design was that a certain CPE type could potentially freeze if accessed repeatedly. When we looked into the statistics we realized that this was really a one in a thousand exception. Furthermore, the CPE firmware had not been updated since installation. Knowing this, the customer decided to handle such exceptions manually, which virtually cut the implementation cost to half size.
Keeping project costs under control
“Processes that look complex at the first glimpse, does not necessarily need to be complex in Netadmin”
Scoping, planning and breaking down requirements and items are key stones to achieve predictability in all larger OSS projects. If one fails to understand the complexity of items early, there is a high risk that the project will take longer time and become more expensive than expected. Since people on both sides often have invested personal stake in the success of the project this may lead to unnecessary frustration and anxiety. Unexpected project costs often derive from unspecified or poorly communicated requirements, poor knowledge of the product itself among stakeholders or failing to see the general complexity of the solution.
To avoid this, we use to following guidelines:
-
Involve the right people early
-
Define responsibilities, roles and mandates
-
Establish good understanding of both possibilities and limitations of the product
-
Discuss and set expectations with all stakeholders
-
Describe processes and flows on different abstraction levels
-
Willingness to change existing processes
-
Avoid over-automating processes
-
Split larger projects into phases
The number of services, access technologies and integrations in the solution in combination with a good understanding of dependencies between different processes, generally gives a good hint of the project size. As supplier we aim to simplify processes and tasks as far as possible without compromising on general requirements. One way of doing that is to treat every technology and service separately in the beginning in order to avoid introducing unnecessary dependencies and parallelism between processes. If we then find common sub processes or components, we will of course try to reuse such parts. This is somewhat an iterative process, resulting in a design on multiple abstraction levels. Some of this work could well be done in workshops together with the customer.
In the end, processes that look complex at the first glimpse, does not necessarily need to be complex in Netadmin. By asking the questions why-what-how for every item, we are often able to reduce the overall complexity and cost of the solution.
Start building your fiber network with Netadmin Nine.
