You will find many instance where users ask for real time in the requirements. Such requirements must always be check carefully for many reasons. This is because real time design is costly. How do you determine the need of real time? These are some standard queries you can ask before you embark on real time design.
A common way to check for real time is the type of system you will be designing. Mission critical system like a car application will need real time design because your car requires instant feedback on the road. Another such system is airline control tower where you will be managing incoming and outgoing aircrafts. Such systems will need a real time infrastructure compared to standard applications. The design is usually highly availability, resilient and fault tolerance.
I want Real Time for Free
The challenges come when your users want real time data refresh in your system. The correct term that you need to use is “near real time”. This means you can achieve data refresh with a tolerance lag of five minutes or more. Another term is “live streaming” where you may design a dedicated pipeline for data refresh. Such design will incur higher cost and must be segregated for your premier customers. In another words, real time requirements should be segmented properly in your product offerings with a cost.
Real time requirements will impact your design and cost greatly. Mission critical systems are real time from backbone to front end. For other applications, real time could be a specific feature. You must always take note that the cost of implementation for real time is always higher than standard requirements. Thus, you must consider these additional cost when you market your products.
Stakeholder analysis is a step you must undertake to understand and evaluate the stakeholders for your project. This step is often neglected, skipped or taken for granted. It is easy to overlook because humans tends to make assumptions for stakeholders. I will loosely classify stakeholders into these categories. You must take note to manage and include these stakeholders from the start of project.
The Good, The Bad and The Ugly
Stakeholders can be divided into the good, the bad and the ugly! You need to focus on gathering these good stakeholders who can play the roles well.
Sponsor to support and orchestra your project vision
Functional roles to implement your project objectives
Influencer to motivate and champion your project goals
Bad and ugly stakeholders are attracted to all projects. This is inevitable and steps must be taken to understand and mitigate their influence. Sometimes, decision must be made to swap these negative stakeholders out.
In every project, it is not surprising to see the wrong stakeholder leading the project. Halfway through the project, you realise a representative is missing for a function group. You may even notice that this repeats into the next project. Thus, it is important to start the project with the required stakeholders with a minimum of 2 representatives. Why? This is because all humans have downtime and you need backup to ensure continuity.
Stakeholder analysis is an essential steps for project success. Identifying positive stakeholders helps to drive your project goals. You must learn to analyse and downplay bad and ugly stakeholders. Lastly, you need to ensure at least 2 representation of stakeholders in your projects.
In the world of limited resource and time, we need to evaluate and prioritise when to implement user requirements. There should be clear guidelines on how requirements are prioritise. These are some of a ballpark guideline to give you a sanity check if the requirements are worthy to be implemented.
There is actually a quick way to ballpark the priority of your requirements. One key method is to use ROI (Return On Investment) model. This is usually used together with data statistics to understand the impact and expected returns. Agile based methodology will view the priority for items that maximise value or benefits to the product.
Setup a Checklist
Before you go in depth to design solution to all the requirements that flow your way, it is cost effective to do a sanity check with a simple checklist.
Impact of Requirements e.g. high volume vs low occurrence
Is there workaround if this is low occurrences?
What is the ROI? Is it a positive gain of value and benefits?
It is now a norm to evaluate requirements to maximise the value and benefits. This is usually overlooked due to external factors such as management pressure and voice of customers. You can use a simple checklist to determine the viability of implementing these requirements.
In every project, scope creep is so common that we have to set boundary with project scope. Some users will request for all requirements with no understanding of story point. Others may become information gatekeeper to reveal scope a little at a time. So, how should we set project boundary?
Vague or Clear
Requirements are always vague in project. Clear requirements are referring to known story points. Soon, you will notice that there are often no issue for clear requirements. You should focus to preempt your vague requirements, if you choose to work on them. Thus, this is where your boundary will start.
Far or Near
If in doubt, do KIV. In reality, this is difficult if you are running on a fixed cost outsourced project. You will want to implement as much as possible. This is where you need to draw your boundary as near to the scope as possible. If the boundary is set too far, the likelihood of this scope acceptance will be very low.
Project boundary and scope creep is a never ending push and pull battle. You can decide this by setting the limits of your boundary. Clearer requirements will often lead to nearer boundary to scope and higher success in your project.
SOP (Standard Operating Procedure) is a very old method of steps to guide operations. It is commonly used for industries that requires a lot of standardisation. With digital transformation, it is highly anticipated that RPA (Robotics Process Automation) will replace many of these SOP. Sadly, RPA is far from being a replacement.
RPA automate Poor SOP
An ideal RPA is an automation of SOP without user intervention. RPA does not differentiate between good or poor SOP. If the SOP is flawed, RPA will amplify that error by a large magnitude. This is because humans could be fixing the poor SOP unknowingly. Therefore, you will be faced with the risk of creating a large issue from RPA.
The Real SOP
Documented SOP may not always paint a true picture of the SOP on the ground. Majority of documented SOP are outdated and not relevant. This is very obvious with system where the SOP is disconnected with the system user guide. In this case, operational users evolve documented SOP with system user guide into a “Real SOP”. This SOP is usually only known to operational users. Thus, it is not surprised that RPA is done for the wrong SOP.
For all the hype of RPA, it cannot be a replacement of SOP. Instead, it is more worthwhile to invest in business process re-engineering (BPR) to improve the SOP.
Business analysis is a fun field because you get to know all kinds of requirements. One of my favorite is “Want All Requirements”. So, what does this mean? This actually refer to the users who want requirements that can cover all kinds of scenarios in the world. In reality, most of scenarios are not applicable. Thus, the user cannot articulate how the requirements will be.
I usually relate such requirements to abstract art. This is because the requirement is subjective to each user point of view. It is so abstract that you cannot really define. It is best to place the requirements in your backlog until you collate enough perspective to interpret with confidence. If you are using waterfall, this is best added to your “parking lot” and taken out of your critical path.
The Sad End
From my past experiences, implementation of these type of requirements always end up unused and unwanted. Majority of these requirements are “nice to have” and strongly insisted by non operational users who may have see such features in other products. Without any linkage to SOP (Standard Operational Procedures) or knowledge of end users, these requirements will meet a very sad ending.
A rule of thumb is to use SOP as a sanity check to ensure requirements are implemented as required. It is a total waste of time, cost and efforts to fulfill “Want All Requirements” knowing it’s sad ending.
Today, I encounter another interesting requirements which state “depends on customer”. Being in project implementation for so long, I am still amused by this response. Why are there such requirements? Do not be surprised as such response is actually very common in Asian countries.
关系 as requirements
Asia cultures plays a big part in influencing the customer requirements. The “关系” aka as customer relationship is an unseen and very strong force. This practice is much prevalent in China, Japan and South Korea. It is no surprise that requirements can change upon customer requests. Naturally, it create challenges for the organisation as system is driven consumer customisation.
Customer is King
“Customer is King” is very common in Asia. With lower switching cost and labour cost, customers tend to be more fickle minded in Asia than American or EU countries. With the differences of leverages, organisations tends to accommodate customers for quick wins. Digital transformation also make it easier for customers to migrate their data across different platforms.
In Asia, requirements are driven largely by cultures. Power is a common play by customers to get what they wanted and as requested. You will usually need local help to elicit and mitigate such requirements. Only then, you can satisfy your customers and gain their trust.
Have you ever encounter vague requirements? What are usually the issues? I will have a standard strategy to handle vague requirements. This is a quick and systematic approach to manage such requirements.
Identify the stakeholders for the requirements.
Get sample data for the requirements. This can be existing data or copies of excel records.
Consolidate user communications and understand interactions of users and the requirements and the sample data.
Agile or prototype to elicit sample data or to clarify the requirements.
Separate clarity and vague once you identify each part of the requirements.
You should be able to proceed on the clear requirements and put the vague part into the backlog.
Iterate the approach from Step 1.
Requirement gathering is never straightforward. Those documented are usually clear requirement while the vague part exists somewhere out there. It takes a lot of practice to clarify vague requirements. You can consider to approach it in a systematic and agile manner.