Product Lifecycle Management (Analysing) – How to collaborate with Client – Part 3

Part 3 – “Devise the solution based on the client’s needs”

In this article, we will use an example from SoftwareHouse that started a relationship with a new client.  If you don’t have your own methodology for collaboration with clients, this article could be of worth to you. I enclosed a lot of materials as processes that you could deploy to your daily basis tasks.

This is Part 3 of the Series of articles about collaboration with clients in the Software product LifeCycle. It’s a continuation, so if you haven’t already, check out first Part 1 or Part 2

Now, we are at the next step of our process, we have a relationship with the client and equally important an agreement with him. We can start with an entire contract and take care of this project and product according to our methodology. 

If you didn’t see the last episode, I recommend just going and doing that. Check the link below. This episode is a continuation, so it is better if you start from the beginning. 

Process – Step 7

During the workshop, we were devising a solution with a report after one hour. This is important as we will base the application on this functionality.

We can’t publish the workshop with the client but maybe at some point, we will create a video of how this analysis would be conducted. Subscribe to this channel or our Newsletter.  Link below. 

In this tutorial, we will take a look at the results of this workshop. The structure of requirements as a model will explain the whole concept of the application. 

The main activities of that kind of workshop are eliciting almost all requirements. You have to remember you have limited time so you need to focus on concretization. 

I can’t recall how we went step by step with this model but I will explain to you everything in detail.

So let’s start:

  1. We add an Entrepreneur at the top of the structure, and we will analyze this model from the perspective of this type of segment of clients
  2. The element “Analyzing and optimizing time spent on a task” will be elicited during the workshop – we can put it on top of the structure of the needs of our client
  1. “Which core business activities are overly shortened or extended” This is a new Business Requirement that appears in the workshop

After all that, we will make some other model without “noises” to show our application from another perspective. That was possible after the clarification of requirements and an idea of how we could solve everything. The game changer in the analysis was the idea of a cyclic summary after some period of time. We assume that after one hour we will send to the user a summary of what he does within this time. 

We have needs and business requirements.  The functional requirement will be defined on an upper abstraction. 

First, we have to write data to the system, next we can report them. 

We divide this application into 3 main functionalities. The first two would be “Save data” and “report data”. Third would be any setting that we have to set so that the App will work strictly with a dedication to the processes and environment of the Client. Those are not innovations in the IT systems but in this model, we can present the Client and the Team members with a solution in the Big Picture. To describe and categorize the above actions, we use Use Cases. You can also use User Story to do that. I like Use Cases, so we will create a Use Case model.

We use it (the Use Case model) but it’s very similar to the Conceptual Model (from the Computer-Science Perspective). The most important is that this model explains applications in a similar way to some HighLevel Design HLD (https://en.wikipedia.org/wiki/High-level_design).

On the above Requirements model, we created some entities with the type “User Case”.

If you create some Models in Product Core Lab, you can use the same elements from Repository. Check how simple it is.

In the Analysis, we discovered a new Requirement and noted it as the Use case “Configure work environment”. We put it at the top of the structure and added a description that on the first use of the application – The user should configure his environment

  1. After putting in this Use case, we realized that we don’t have an idea and solution to what should happen if the user turns on the application. What would be the default screen to display to the user?  The inspiration for those questions was us realizing that we couldn’t use applications without the configuration of the environment. 
  2. We added a new Use case “Turn on the application” – We have to approve it with the client. But we need some ideas and we have to take care of the above scenario
  3. Next, we could assign the risk to the project. The risk here is that the user would not be able to understand that to use the application he should configure the work environment. 
  4. Additionally, we put “work environment”.and “work environment settings” into the dictionary

It’s a great moment to create a new “risks model” 

Adding the descriptions with mitigation ideas – In ITGP, we always propose to our client some ideas to mitigate the risk. This is the part of the analysis that we perform on our client

  1. Change the type to Risk
  2. We have to comment here that this is the risk that could materialize only when we will sell the app on the market. If our client will use it and will know the process he, of course, will understand what and how should be configured in the work environment.

Let’s go back to our User Cases to add Descriptions. In this phase of the project, the most important is to add main scenarios and main alternative paths. This will help analyze everything with the client and our technical part of the team.  

Process – Step 8

In the further step, we need an Internal Business Analyst session. Here, we will have a creative session and take the time to devise a better solution. 

We have to take some time to check everything again after the workshop. We have to make sure everything is correct and consistent. Think about fulfilling business requirements twice and send them to the Client for approval.

Now we can send to the client our software documentation and prototype application as a model.

The next step after all that would be real prototyping and estimation. 

Sign up for our Newsletter, we let you know about the next episodes how you can do everything in the Product Lifecycle Management, and of course how you can estimate projects in Product Core Lab, 

About author

Karol Kordziński - Business AnalystI’m Karol Kordziński from Poland . I’m an analyst with a couple of years of experience. I’m the owner of ITGrowPartner where we help small- and medium-sized companies analyze projects.  But mainly I’m the owner of Product Core Lab. Saas tool to manage a product in the whole Product Lifecycle. With this tool, you can explain your product and processes in a structural method. We introduce you to how to model software products step by step

Leave a Reply