Edit

Implementation pitfalls

Scope creep

This pitfall is applicable to POC projects mostly, as the scope is fixed in them unlike in production projects that follow agile workflow. Naturally, customers want to get the most out of their money and often try to squeeze in additional tasks in the process of implementation. It is also normal that good ideas of new features appear once scope was agreed and implementation has started. Otherwise, the dev team might be getting such requests from SMEs they work with and who do not necessarily know what scope of work was agreed so propose new features that they believe will improve the process. The most important aspect here is to recognize in time that scope creep is happening. For that you need to be well acquainted with the contract on the one side and with what developers are actually doing on the other side. If there's divergence and a risk of timeframe and resources extension, it is necessary to re-align expectations with the manager and team from client side and tasks with the dev team.

To avoid scope creep:

1. Write a design document based on requirements before implementation start and receive written sign off from customer that it is what they expect;
2. Do not reject new feature; suggest to put it on a list of features to be considered for the later full-scope project/production implementation;
3. Explain the full consequences of proposed action that are not seen by the customer. For example, a request to simply add one more field to the model training in the middle of implementation might mean re-tagging of the whole dataset tagged so far (even though to add only one field to the tagged ones), booking customer SMEs again for this period; re-checking of the same dataset by DA; adjusting the manual task and all related bot steps, possibly; retraining the model; writing post-processing for the new field. With all that the timeline is inevitably pushed forward. So, depending on complexity of the ask, you can estimate the time and resources needed for the change (in this case SMEs, MLE and DA) and ask if the change is important enough for successful proof of concept.
4. Re-iterate the purpose of POC - to prove that functionality works + potentially identify items to be tackled in the next phases/production. All the new fields, rules and dependencies discovered are falling well under the second category and it is normal that they appear when you dig deeper. Trying to add them to the current scope is more of an obstacle of reaching the POC aim of producing a working MVP. Remind of the need to apply 80/20 rule for quickest outcome of the greatest benefits and address remaining opportunities in future reviews.

Implementation team: insufficient or wrong skill set or experience

Make sure you're starting the project with the right team. Based on use case specific and project plan you're able to identify needed skillset and correspondent number of resources of each role. When defining what people should be involved into project consider the following basics bullet items:

• Evaluate candidate's previous experience and it's relevancy to your project.
• Get feedback from previous involvements of the candidate.
• Make sure candidate has correspondent certificates in Automation Academy.
• Depending on the project you might also need to consider candidate's foreign language, ability to travel, and so on.

If you still got team members with wrong or insufficient skills into the team, do not panic. Depending on the project duration you might have a chance to get them up to speed with necessary knowledge and skills. If you do not have enough time on project schedule, either try to replace a team member that doesn't fit or just add more senior resource into the team for guidance and mentoring others. Your focus as a DM should be successful delivery of the project and happy client in the end, but please also keep in mind that mentoring and guiding team members is a very important part of your responsibilities.

When the project is finished do not forget to note feedback on every team member and share it with your colleagues, so that they could pick proper team members for their next projects.

Customer dependencies

During use case implementation you will always face dependencies on 3rd party (usually client). Frequent examples are: hardware or software needed for the implementation, questions on requirements, documents and other use case related data, progress and schedule of the other team you need to integrate to, and so on.

It is strongly recomended to define list of critical dependencies on early project stages (preferably on estimation and planning phase) and manage them as project risks. In a perfect world all these critical dependencies should be listed in SOW as pre-requisites to successfull delivery, however it is not always possible to have all of them defined on early project stages.

Maintain list of critical dependencies always actual in terms of severity, potential impact and planned dates of resolution. Keep it transparent to the client, team and all involved parties. Regular project meetings should include walk through sessions where you should be highlighting most risky dependencies and their impact on budget or schedule. Focus on helping to find solutions or workarounds to customer problems, not on proving that these problems are not yours. Otherwise, at the end of the project you might find you were right all way through but customer is unhappy and the project is not seen successful.

Project underestimation

Underestimation is a regular pitfall faced by all DMs. As a result you might run out of budget before you successfully deliver the project. When faced on a project, try to do the analysis of the reasons of underestimation. It could be insufficient information provided by client as well as mistakes done during initial project analysis. Sometimes it could be related to misunderstanding on client/team side of what should be done in scope of use case implementation.

As always DMs focus is successful delivery. Work closely with client to understand what could bring you back on track in terms of budget: cut down the scope, agree with client for additional budget allocation or take a decision to cover exceeding budget at the cost of vendor.

The important thing is to learn the lesson why underestimation took place and how to prevent this in future. Make sure factors that impacted the original estimate are considered during future project estimations.

Budget and schedule slippage

Rule of a thumb: DM should regularly track project budget and schedule. As soon as you notice the possibility of being behind the schedule or out of budget you should understand the root cause. Very often the root cause will be one of the above pitfalls, but it could also be many other reasons: underestimation or wrong planning, misunderstanding of requirements or success criteria, bugs in automated apps, and so on.

While it is important to understand who's responsibility it is, your focus should be on getting back on track in terms of schedule and budget. Depending on the use case/client/root cause specifics you might consider agreeing with client to increase the budget or prolong the schedule; decreasing project scope could also be an option. As a vendor you might also consider a decision to cover budget slippage or add resources to get back on schedule.

The main recommendation would be to focus on successful delivery and leave searching for guilty for retrospective or post-mortem.