If you’ve never seen an effort estimate miss reality, raise your hand. Conquered by optimistic estimates and seductively low costs, the first best offer is chosen. The complexity is nevertheless small and the promises of the proposal dreamlike. Then reality strikes and change request after change request drives up costs.
Here’s the good news: It doesn’t have to happen inside your project. With the right knowledge, you can shake castles in the air by skillfully asking questions and approaching a realistic estimate again. This article is dedicated to the underestimated topics of such projects. At the end, you know where you can challenge your estimate again. Ready? Then let’s get started.
1. Changes in requirements
Let’s start directly with a topic you can influence by yourself. In practice, it is far too often the case that requirements change again and again in the course of a project. That’s not surprising at first. Decisions must be able to adapt with increasing knowledge. In projects, however, decisions are sometimes made hastily and then reversed. This can be avoided. For example moving a button from left to right and back is supposed to be a small change. But it creates dependencies, e.g. development, communication, and testing. Not only is this expensive, it also demotivates the developer. This can and should be reduced by planning and defining the requirements and wishes in advance.
2. Error messages and error handling
Your online service is intended for the end customer, the integrated back-end system for an experienced specialist. The small but subtle differences are often neglected. Error messages and error handling therefore belong to the less considered cost drivers. Multichannel Foundation for Utilities is directly integrated with the IS-U and possibly the CRM system. If the error messages from these systems are not replaced or intercepted, they are transmitted to the customer unfiltered. This is not only partly incomprehensible for the customer, but also not desirable for you. Therefore you should think about the possible error cases. It can be useful to use generic error messages for unconsidered cases. Considerations about this not only increase planning reliability, but also reduce the risk of unwanted surprises in productive operation.
3. Contacts and notifications
After a process has been performed in your online service, you probably want to inform your customer or employee and add a contact to the business partner. Your ideas should be planned and communicated well in advance. For which processes would you like to carry out which action? Are there any restrictions? If, for example, you only want to send an e-mail to a certain customer group, it is possible but also an unexpected effort, if these requirements are addressed for the first time in the middle of the project. It makes sense to consider the desired variables, the recipients, but also the text and layout from the outset. In the case of contacts, for example, the link with BOR objects should also be considered in advance. Should your customers upload files? Then you have to consider the file storage location and the virus check.
4. Alignment and coordination between back end and frontend
For an online service which is directly integrated into the back-end system, the coordination between both is important. The developers of the user interface should have a basic understanding of the processes to be mapped. And they should closely work together with the back end developers responsible for the online service. The Multichannel Foundations for Utilities OData Services aren’t self-explanatory, so it makes sense to place the two teams in one location. Tasks should be designed to avoid downtime on both sides. However, coordination is also necessary outside the purely online offering. If interfaces which the online service accesses are adapted, the functionality has to be tested again. The recommendation of our customers is to use providers with deep industry knowledge for frontend and backend implmentation. Based on our experience, the design can be outsourced to a web agency without complications.
I would like to conclude with the most important topic. You should never neglect tests in a proposal for end customers. The proverb “There is no second chance for the first impression” applies here. Sufficient time should be allocated for the tests. It is too late to start testing two weeks before going live. Reasonably plan with at least two test waves. Following the initial test, a timeframe for corrections and developments should be established. Afterwards test the entire service again before productive operation will start. During testing, it is advisable to position the testers and developers together. This allows developers to react more quickly to errors and discover ambiguities during use. Use the time and opportunity to correct any known errors before going live. Hasty emergency corrections must be prevented.
These are the five most underestimated topics in Multichannel Foundation for Utilities projects. Best of all, these topics are quite universal. In your next project, you will assess these topics directly and address less obvious effort drivers.
Do you have feedback from your projects which is useful for others? Any questions? Then leave a comment or contact us.