Some of the common expectations from a software application as an end user can be broadly classified under functional and nonfunctional requirements. Functional requirements are those which help the user solve their specific problems. Nonfunctional requirements are those requirements which indirectly adds to their experience of using the application. The user’s expectation on both functional and nonfunctional requirements increases if similar applications are in the market. For example, a new email service. The user expectation, will be high on both functional and nonfunctional aspects as the solution to the problem is well known. So here, you would find that the user expectations are ahead and the solution is trying to catch up with them. These solutions are stuck in this race till the solution offered is at least 10x better than the existing one's. That said, if new problems are identified and a befitting solutions are offered or a 10x improvement is offered from existing solutions, solution would lead the users.
Solution leads the User Expectation:
A startup which chooses to identify problems and build solutions from scratch has to iterate to validate assumptions and figure out what solutions best fit to solve a problem. At Lean Station, we had to take the exact above approach because we were the first to address this problem in the market, a disruptive application. We built the functionally working features giving the maximum weightage on the functionality itself and give a reasonable weightage to the non-functional user experiences in our earlier iterations. We take customer feedbacks to iterate and continue till it is operationally suitable and stable.
Now, we have been building Lean PlanDo for over 2 years and have reached a phase where main functionalities and the crux of the methodology are streamlined. We are now beginning to concentrate on the user experience aspects of Lean PlanDo. I am highlighting one of the major improvements out of the many we have added - speed and performance improvement of (Precision Diagram Method) PDM calculations or simply put the backbone algorithm that calculates the effect of complex dependencies in the project and calculates iteratively the new dates for all the downstream activities and recomputes the project end date in real time.
I will have to start to get technical from here on, all the non technical readers, see you at the end.
The old way: For calculating the early start and early end dates for an activity, each of the successor activity is taken in isolation and early dates are calculated based on its predecessor dates. The entire project activities are loaded and early dates are calculated for each activities. It loops till there is no change in the early dates calculated for all the activities. Even if a single activity’s early dates calculated did not match with it’s previous early dates computed before, it looped for the entire project, which means, at least two loops were required to figure out further looping is required.
Because of the way it was designed, it consumed time. To circumvent this issue, we decided not to auto run the PDM on delay or advance of activity, but have an “Update” button using which the user can trigger to run PDM manually.
The new way: It is evident that the above design is not optimal. Also, the manual intervention required by the user is not a desired way to have an updated plan. This functionality underwent sufficient iterations before functional expectation was fixed. It was now time to improve the performance and also remove the undesired “Update” plan. Also, in near future we want to support dependencies between tasks belonging to different activities. By this, the complexity and execution just gets doubled. Keeping all the above requirements, a total revamp was done to improve the performance and reduce the execution time.
Below are the comparison metric and charts which give the insight on the improvement of the execution time.
Comparison of Old vs New PDM:
As part of the continual improvement, the above graph shows a reduction in response time by approximately half the original time. This gain in performance will only increase with increased number of dependencies and complex dependency network because of the new approach taken. While the value addition on the feature list continues to grow in Lean PlanDo, more such non-functional aspect be delivered in parallel.