Pre-implementation analysis as a "guarantee" of your project success

Find out why it is worth getting to know your system well before its implementation.
16 February 2021

The designed IT system should, in general, fulfill the assumed functions and predetermined goals. However, despite all efforts, not every project ultimately becomes successful. To save you from that disappointment, we would like to discuss some factors that determine whether a project will be a success.

Working on an IT project is a comprehensive process, and it does not matter if you go for a small application or an extensive platform. The plan itself comprises separate stages and a series of tasks. Their mutual goal is to develop an IT product tailored to customer requirements. Having expertise in the field, we agree on one thing. A critical factor that largely determines the success of such a project is the pre-implementation analysis.

What is pre-implementation analysis and why is it so important?

The pre-implementation analysis is a series of activities undertaken at the stage of preparing an IT project. Their primary goal is to translate business assumptions into the technical description. So we can say that it is a specification of all work that must be done to successfully implement a product.

By now, it should be obvious why you shouldn't take the analysis lightly, not when you're implementing a new system, or improve the one you already have. Unfortunately, many entrepreneurs and suppliers underestimate its business value. In the eyes of clients, it is often a pointless action that generates avoidable costs and does not contribute to the project at all. It usually hides under the attitude: "I hire a professional to get it done”.

Suppliers often skip the topic on purpose and for a good reason. During the analysis, they run into the risk that their product may be unsuitable for a prospective client. To avoid it, the client simply gets a properly conducted needs analysis document. It describes how their system features will operate within the client's system.

If we perceive the pre-implementation analysis as a useless tool, we are bound to face many problems during the stages of programming and implementation.

For example, Joe, a store chain owner, wants to expand his business and start selling over the Internet. He goes on the internet for IT suppliers hunting. Finally, he finds a decent Software House. Their offer covers eCommerce implementations and, so he sends them a business inquiry. He briefly describes his needs and what features his online store should have. From a client’s point of view, the inquiry makes sense. At this point, the IT supplier faces the following dilemma: How am I supposed to offer and quote something with that little information? That is a real problem from the IT point of view general inquiries contain rudimentary or no useful information they can use.

Let make a simple and down-to-earth comparison. Let's say you are is planning to build a single-family house. In the scenario, do you ask the real estate developer about the construction cost, the square footage, and the number of rooms? Being given that information, are you ready to take that offer and buy that house right away? My guess is no... You would want to know more...

Even so, the issue is very common in the IT market. Incoming requests for quotations are ambiguous. It is very difficult to determine the IT project's scope of work, its budget, or schedule even.

Then, how do the IT companies create a quotation for their services? There are 3 possibilities.

  1. Just to reply to a prospective client inquiry, the IT suppliers send their common offer without asking for further details. The nature of the response is very general including the project's scope of work, the budget, and the schedule vary.
     
  2. The second, yet more comprising, quotation option. You have something that is more specific than a general reply and much less specific than the actual pre-implementation analysis. The IT supplier can either offer a short meeting, a videoconference, or ask you to gather extra implementation details. In the scenario, you get a preliminary estimate comprising many IT product and budget variants.
     
  3. The best and the most optimal option is the full pre-implementation analysis. Once the Software House gathers all required info, they could present the offer to the prospective client. The result itself is the IT specification document which describes the specific company’s needs and business goals. Only after doing that, they create the project implementation price list.

It is no surprise the actual pre-implementation analysis holds the water. Both for the IT supplier and a potential client. On both sides, it is possible to form the most informed decision on the IT project and check if cooperation can move forward.

Still, why is the pre-implementation analysis the best solution?

There are other reasons for investing in the pre-implementation analysis. As a client, you get to control the project. It helps to avoid misunderstandings and overcome frequent challenges during the implementation stage. Also, the supplier knows your final expectations and works towards meeting them. Reaching such a consensus is probably the hardest challenge for both project sides, yet bodes well for future cooperation.

What frequently happens is the client sends a proposal request with a fixed solution. It does not come from ignorance; it is overall good that the client knows what their company’s actual needs are. The problem lies in being oblivious to the solution’s complexity and the fact that during the implementation stage results may simply change - as the additional needs may come into play. Being open to that approach helps to avoid any additional costs and prolonging the project’s implementation time.

To prove that, we would like to recall Joe, the store business owner who wished to sell online. He will be the protagonist of our story. Joe is already past selecting his IT contractor and the works on his store have begun. Yet, during the implementation, he has changed his mind about some store features. They became unnecessary, and there is no need to introduce them. Instead, he would like to introduce other modules and features. However, the work on Joe’s online store is already underway. Sure, it could have been even worse, Joe’s project was nearly completed. What should the IT supplier do with the time spent on the project development? Also, it is unknown whether introducing new modules or features will be possible to do. What about Joe’s planned budget for the investment? Who should be the one to cover the additional costs and bear the consequences of "not completing the project on time"? Being aware that such an issue can happen, surely lets everybody involved avoid it by applying necessary measures, i.e. the pre-implementation analysis.

Still, there are no guarantees situations like this won’t happen, yet you can avoid a lot of issues at the beginning. In IT projects being proactive and cautious significantly reduces these projects’ risks.

What are the clients’ benefits related to the pre-implementation analysis?

  • Project cost real expectations
    During the analysis, the client receives the official document which covers all the most important project’s aspects. Thus, it is much easier to control the costs. The fewer unknown variables we have, the more accurate the pricing is. The project’s quotation shows exactly the conditions both sides have agreed to. The analysis itself has an additional fee, but in the end it brings measurable savings.
     
  • Reducing the project’s implementation timeframe
    Establishing and knowing all the works within the IT project allows determining more accurately the entire schedule while minimizing the reserve buffer. Better planning and resource booking required to complete the project work at any stage way efficiently. As a result, we reduce the downtime caused by several reasons. For example, the IT supplier may need to wait for key information, or for delivering resources that are missing.

  • Introducing changes to an existing project
    The pre-implementation analysis gives a chance to see how the system will look like and operate before it’s finally implemented. It’s a significant advantage, as the client can verify the preliminary idea or even "test" it with company employees in the everyday work environment. Let’s say, some client’s expectations do not match or work how they were supposed to. Then, the IT supplier can still change it, taking no drastic measures, or even avoid additional costs.

  • Increased chances for a successful IT project
    After the analysis, both the client and the company are on the same page in terms of the organization’s business needs and expectations. There is a much greater chance to complete the project with success and guarantee all project goals are there.

  • Performance guarantee
    Defining a list of system features provides a point of reference for the client and the IT company. Once the project is complete, there comes a time to verify the final implementation result. If the system failed to meet the defined assumptions, you can always refer to and rely on that specification document.

  • IT Consulting
    Hiring an external professional IT company is something our clients practice often. The overall benefit is identifying internal issues by an outsider that otherwise wouldn’t have been discovered. It may lead to a significant and valuable discussion. The client may want to ask questions, while the IT supplier will provide a professional answer.

  • Getting to know the IT team
    As the analysis ends, both companies and teams already have some private impressions of each other. Use this time to reflect on how the cooperation is going. Watch out for a ‘green’ or ‘red-light’ during this time. These signs may show you how well or simply bad future project cooperation might look like.

What are the pre-implementation analysis benefits for the contractor?

  • Clear expectations
    The stage of analysis allows to combine the client's and contractor's vision on a project and see how well it fits together. The better you systemize all the system requirements, the clearer picture you get. Because of working together, both sides create the full software specification. The IT contractor's team learns what their tasks are, and what they are working towards. It makes the collaboration simpler to control, helps to avoid frequent misunderstandings.
     
  • Planning the work schedule
    Proper work planning makes it possible to include all your company’s needs and expectations. It lets you keep track of all project tasks, even if your supplier is running several parallel projects. The IT supplier armed with a plan can optimize the task workload and the overall working time. It guarantees no standstills, and all project tasks can continue with no interruption. While the IT supplier is planning out the system features, the team can detect potential errors in advance. In the end, it shortens the implementation time.
     
  • Client’s involvement in the IT project
    Unfortunately, the lack of customer involvement presents a common problem. In that scenario, the IT specialists have a tough nut to crack. It is up to them to decide on certain systems issues or nuances. Some situations require the client’s attention more than others. Faced with such issues, it leads to an unwelcome frustration and further project stagnation. To avoid that, during the analysis stage, it is essential to build for yourself a strong partnership with your IT contractor. It should have a solid foundation based on collaboration. Once, both sides get these things out of the way, and discuss their approach toward the project, major issues simply disappear. The only ones that remain to discuss are minor details.

What does the pre-implementation analysis involve?

This type of analysis varies in terms of approaches, a lot depends on the customer’s and the provider’s partnership. Let’s not forget, selecting the work method plays a great deal. The analysis process runs along these lines:

Pre-implementation analysis diagram

In the diagram above, you see that communication is the basis for successful implementation. The interviews with the client’s team are key. Their goal is to discuss and define all system operation expectations and technical requirements. Then, the consultants gather all information to plan the project tasks. All this, to get to know the client’s business environment and the current company situation. That is how we end up with a comprehensive IT project document. It contains your company’s business needs, along with the specification of the functional and non-functional requirements.

It is possible to divide the pre-implementation analysis into 2 preparation stages. One covers the business analysis, while the one deals with the IT requirements specification.

The business analysis is about defining particular business processes within your company, while the project implementation unites all of them into one system. Defining all these variables separately at the very beginning is significant, as it reveals their relevance and puts them in a center. First, you take a careful peek inside your company, get to know how detached features, processes, and elements operate together. Then, it is time to define and agree on what and how to connect them all into one well-oiled machine, i.e. the best IT business solution. Sometimes, implementing one, yet a specific business change may work miracles. It has one more beneficial aspect to it, allows you and the IT supplier to detect any discrepancies or aspects that are possible to automate and optimize.

The pre-implementation analysis strives for designing any business processes models with the corporate taxonomy. To visualize the company’s complex processes, we frequently use specialist diagrams. One of them is the BPMN, which stands for the Business Process Model and Notation. Or the EPC (Event-Driven Process Chain), or the BPEL, i.e., Business Process Execution Language. The most popular BPMN, Business Process Model, and Notation is versatile because of its well-described meta-model. Most tools and various BPMS (Business Process Management System) systems on the market support the modelling notation approach.

BPM analysis provides answers to such questions as:

  • What and where are the enterprise bottlenecks?
  • What are the organization's factual business needs?
  • What company processes require optimization and automation?
  • What is the average time and cost of these separate company processes?

The pre-implementation analysis covers all tasks connected with defining the requirements specification. Here, the IT team grasps the entire concept of the system design. The document describes in length the following elements:

  • Functional requirements (FRs) are all product features the system can offer you. Also, it defines how the application will behave under specific conditions and in a definite environment. The purpose is to show the overall system vision and its objectives, and its development context.
  • Non-functional requirements (NFRs) are the constraints and standards the system has to match. They concern such issues as performance, availability, reliability, security or system scalability, and compliance with any legal standards.

During defining FRs, applying the Use Case models (UC) is an inseparable aspect. The idea is to present the system services via a graphic and interactive representation to a user. At that moment, we are testing out the user-system interaction.These UML notion diagram models comprise several elements, e.g. the actors, use cases, and system object association and dependency relationships. In the scheme, the actors are the administrators, vendors, or clients, basically, anyone who interacts with the system, and has a specific system role. Whereas, UCs are particular actions that you perform in a system. Associations between UCs determine the system’s behavior scenario.

Describing any system modules is equally important. It happens during establishing the functional requirements. To visualize how the module features work and verify whether they support arrangements, the IT teams prepare system mock-ups. If everything goes smoothly, later on, they turn into prototypes.

The mock-ups are less than prototypes, yet much more than wireframes. They show precisely how the final product version will work and how the users interact with the system. It is a chance to form your impression of the system design. By looking and clicking on the mock-up, you see its layout or whether the placement of page blocks/elements is logical and intuitive. The mock-up approach is invaluable from the IT point of view. Already during the analysis, you and your IT company, we can catch any inconsistencies and verify whether suggested ideas will work out.There is one more benefit here, separating the visual aspect from the conceptual one. Most people are visuals, they focus on colors, style, or the content. With IT projects, 100% of our attention should be on the system functionality, its overall concept. Mockups do exactly that. Let’s briefly summarize what mockup show:

  • the main page view and key sub-pages view, along with their descriptions,
  • layout and blocks’ description including their features,
  • layout and activities’ description system users and administrators perform.

Surely, before developing a mock-up, the IT supplier develops and describes the company’s AI (Information Architecture). Usually, it either a service or a system map. We define the mentioned AI, its hierarchy, and the naming system. We have designed platforms comprising hundreds or even thousands of intertwined various data types. Arranging it all transparently makes it for the users easier to work on the system in the future. Information architecture connects to the usability engineering principle, user experience (UX) design, and knowledge management.

Although the non-functional requirements (NFRs) do not directly refer to the system’s features, they have a tremendous impact on the system's quality, efficiency, and operation. To put it simply, they focus on the technical parameters and software configuration. You could say they are like system guards. NFRs make sure the standards and restraints in a system are meet 3 vital aspects:

  • Application performance, i.e., requirements include the system’s effectiveness, efficiency, reliability or scalability,
  • Business operations, i.e., all aspects related to the company’s business strategy, prevailing standards, values, implementation method, programming language or operating system (OS),
  • System environment, i.e., all external factors, namely legal or ethical requirements, including security measures, integrations with external systems.

In reality, the project list you should compile with your IT contractor should be very long. On that checklist, include for sure your business goals, system technical parameters, and the overall scope of work. These are quite standard ones with IT projects. However, it still all depends on what you choose, the system or application type, and the IT environment you have at your company. Let’s say you need to design a system that requires several integrations with other systems, like ERP, WMS, and external payments operators. The work on the project would involve adding special rules, so the all systems would work smoothly together. In case you would want to replace your current system with another, you need to make sure it is possible to migrate data. Plan it to reduce the downtime to a minimum.

If you and the IT supplier conduct the pre-implementation analysis, you will be on the same page, running the same project. Establishing the partnership ground rules, having the same knowledge on the project will do you no harm. The pre-implementation analysis will help both of you to estimate the project budget, its schedule, and the scope of work.

To sum up, the pre-implementation analysis is a success if:

  1. Company business processes are well-defined,
  2. The project’s goal and the expected outcome,
  3. Functional and non-functional requirements outline,
  4. Module or feature list along with its application and operation,
  5. Information architecture (AI) model.

Remember, create a transparent and put document for both sides: you and your IT contractor.

Yet, is it possible to embark on a project without pre-implementation analysis?

The current market proves it is possible, but... Exactly, there is a “but”. It is the huge RISK you take on, and no project scope takes to a whole new level. What we know is large and complex projects require an in-depth pre-implementation analysis. With a simpler project, IT expert advice and close cooperation between companies may be just enough. However, nothing is safer than a professional pre-implementation analysis. The overall benefits outweigh its costs and translate into real savings in the long run. It is not a free service, yet you get your money’s worth.

Running grand IT projects has nothing to do with luck, but diligent preparation of the entire teams. It is nothing like the proverbial box of chocolates or buying a cat in a sack. It simply does not stick with IT. What does? The pre-implementation analysis. It is your guarantee the project start will end successfully, and you will end up with exactly what you wanted.   

Contact us

×

Leave your contact details and describe your needs. We will contact you back as soon as possible.

Clients about us