What will be the timeline of a project in RPA?

data process

Most RPA deliveries are agile, scrum, pair programming etc. the thought of RPA is to deliver automated processes incrementally within a couple of weeks or months as against some 3–5 years waterfall projects. A sprint within the agile world normally takes about 2–3 weeks and therefore the expectation is to possess working components in 2–3 sprints which will be released into production delivering benefits.

The number of process of a project may influence the timeline. a small process may take 1 week collecting data, 2 weeks of development and a couple of weeks of testing before deployment to production. Tentatively, a medium sized process may span 6–8 weeks following a release into production.

In the case of an outsized process, this might take 4–12 months following a release into production. A typical example of this is often when a process is introduced as an initiative to either eradicate or reduce the manual process to an excellent amount. this needs tons of development, testing and most of the time going back and forth till the client/business SME is fully satisfied to log off on such a process.

Other factors may influence the timelines of a process:

Technical expertise:

If the developers or testers are under-skilled or relatively new the technology, most of the time could also be wasted understanding what the tool can do or cannot do. you cannot compare an experienced developer to a newbie. An experienced developer can have a process built to plain within 2 week and a half and thorough testing wiped out 2-3 weeks, thereby piloting the method in but 8 weeks.

Test Data/Systems:

Most of the clients do not have test environments for his or her applications or necessary test data to effectively conduct a UAT assessment. this might constitute some delays within the UAT assessment and further delay the progress of testers, who are liable for that test cycle.

Some clients perform controlled live test with developers and testers during a monitored manner and subsequently, you finish up going back to development once a defect has been noticed.

Do not get me wrong, doing a live test is good and well advised but developers should have proper skilled unit and configuration testing before this to make sure minimal changes will be made during the live testing with client SME

Inadequate business requirements:

If the business requirement gathered by the method analyst or the business analyst isn’t concise, several requirements could also be missed and longer is spent rotating between development and testing because the process behaves differently with some inputs as against the expected behaviour

Proof of Concept:

From my observation, tons of individuals spend such a lot time doing POCs. From my research, the time spent varies from 2 weeks to six months. After such vigorous exercise, you will guess that implementation may take an identical trend of two weeks to six months hence, no benefits are realised on time.

In some cases, the method could also be passed on from one individual to a different as they move along to a replacement role and sometimes it is going to end in an abrupt end.

Most times, passing knowledge could also be difficult thanks to the intricacies of the method. I strongly recommend creating a Minimum Viable Product (MVP) before the ultimate solution because the MVP are often released into production earlier enough and therefore the business can enjoy the E2E solution

Solution complexity:

Some solutions involve advanced technology like surface automation, OCR, machine learning etc. they are not as straightforward and are very time-consuming.

Stay Safe and Cheer !

August 22, 2020