Agile is the buzz word singing around IT projects nowadays. Every project needs to be agile. Prince II rapidly became old-fashioned. You can’t even remember how we managed a project successfully in the old days ?. During the latest projects we supported, we also made the transfer to working in a more agile way. We have learned some valuable dos and don’ts when implementing agile in an HRIT project such as a Workday, SuccessFactors, Oracle Fusion or Talentsoft So what are the The Do’s and Don’ts doing HRIT projects AGILE?
What is the difference between Agile and traditional Prince II projects?
Working agile is adapting a new project methodology and a radically different way of working. Agile relies more on team strength to determine what they are able to finish in a certain timeframe. The main focus is on delivering real value for the (end) customer
Sprints vs long term project plans
In typical Prince II projects, it is the Program manager who determines what will be done and when the go-live dates are set. We used to plan two years ahead. Needless to say, this was not often very successful. In the agile world you still make a plan but now you start working towards the goal in sprints. A sprint can be around 2 to 4 weeks. The team commits itself to a specific task that they will finish during the length of the sprint. Preferably, you actually finish a product so it can be delivered to the customer. For HRIT this implies the need to ensure that you have done testing and created training material, preferably within this timeframe. The result of the sprint can then be demoed in a Sprint review session where the end customer is present. The benefit is that you will have feedback on your product within 2 to 3 sprints. So if the customer is not satisfied, you will know much sooner than in traditional projects (which often only include the end customer during a UAT when the total product is finished).
During a PI Planning, all teams and all team members are present. The program manager, together with the product owners, will set the priorities for an upcoming period (e.g. 3 month). Based on the priorities, the teams will determine what can be done and when they believe it can be successfully executed, within the given timeframe. In a couple of iterations, each team determines whether go-live dates are feasible and really commit themselves to it. The teams also look at interdependencies with other teams. The advantage is that the interdependencies are clear before you kick off the next three months and Scrum Masters can and must solve any impediments.
Daily standups are a powerful way of working to create commitment, get alignment and continuously track if everybody is on schedule . Because many of the tools are built around visuals (such as a Kanban board) all team members can view the status and progress of the team.
Minimal Viable Product
As mentioned, in the agile world you preferably build, test and deploy small pieces of new functionality and start using them, so the team(s) deliver a functioning value-adding product. A typical example can be seen in banking-app development, where functionality is added every two weeks. The product goes live as soon as it adds value, and new functionalities such as FaceID, QR-code scanning etc. are added in a later stage. The main benefit is that the customer can already start using the app in an early stage and can give feedback to the developers for improvement.
What are the Dos in agile HRIT projects?
Make it Visual!
Visuals are a strong way to create clarity. The use of post-its on your KanBan board at first sight looks amateurish, but has actually proven its value. It works better and is more inspiring than an Excel or PowerPoint planning. And it’s an invitation to start a dialogue.
Team effort, Daily standups, Sprint reviews, PI planning
Working together, asking teams to buy in for the new 3-month planning, works very well. First of all, bringing the team members together creates transparency and a positive form of peer pressure. Secondly, people no longer hide behind telephones or emails but actually solve impediments together. Simply because we are together in one room. And last, during a PI planning, you typically plan 3 months ahead. This is a clear period to make a realistic planning.
Build your MVP and iteratively improve on it
In the typical HRIT project the MVP is a configured full working module , for instance recruitment. In general, the end customer is not interested in the job requisition process alone, when the rest of the recruitment process is still handled in other systems or even manually. Therefore you initially need to go live with a fully configured and tested module. So, Spec minimal, build the MVP and improve in an iterative way
Introducing a DevOps team
In the traditional projects we have realized, you have a Project or Development organization that ensures the project and build is executed. The project organization than hands over to the support organization. This often leads to friction, because a project organization wants to move on and in general hand over to support when they are almost done. The support organization realizes this and puts up a barrier by creating an extensive list of acceptance criteria. With the introduction of a DevOps team you merge the Development and Support organization to form one team. One of the substantial benefits is that the people who build the solution are also responsible for maintenance and support. Needless to say, the quality of the product that goes live is much higher and people are much better informed and trained
Don’ts in an agile HRIT project
Remove program management and Steering Committees
HCM programs are often large HR transformation programs. In the majority of cases, this goes hand in hand with changing processes and re-thinking employee experience. As a consequence, these programs are based on a long-term vision, most likely taking 1 to 3 years and have budgets of >2 million. By removing the traditional governance bodies, first of all you run the risk that no one will secure the long-term vision. Secondly, maintaining planning and cost control is vital for most of the companies we have been working for.
Manage your HRIT project as if the budget is an outcome
Some gurus we have talked to said: “in agile, the budget is an outcome based on the ambition level.” Fair point… when you’re in Disneyland. All the companies we have been working for still plan in annual or quarterly cycles where projects have a fixed budget. It is true that 90% of managers believe the budgeting process is useless but 90% of the companies still use budgeting to plan their business.
Develop from scratch in two-week sprints
We have seen that building from scratch, without specs in two week sprints does not work because there are too many dependencies in such a large project. It’s not an app you are bringing live. As mentioned above (Dos) we learned that it is best to create minimal specifications, then built an Minimal Viable Product. (The bare minimum). Next step is testing (including end customers) and receive feedback from users. Last step is to improve the product in an iterative way until the product is ready for deployment.
Forget milestones and rely only on team effort
What we have learned is that teams still need direction: “when you’re at an intersection with seven directions and you don’t know where you want to go, you can take any road”. Starting a PI planning session with a blank piece of paper just doesn’t work. In such a large project, it still works best if teams can rely on milestones and clear goals that are set in advance. Of course milestones need to be realistic and any impediments need to be solved.
We hope this blog gave you valuable Do’s and Don’ts doing HRIT projects AGILE. Please do not hesitate to contact us if
Bas Eggelaar, Program Manager at SuccessDay. Currently supporting as Program Director a rollout of SAP SuccessFactors full suite as part of a HR transformation Program. Global client (26.000 employees) headquarters in The Netherlands.
We are SuccessDay and we strive to make your implementation a great success! SuccessDay is the independent advisor during your HR IT implementation. We operate next to the implementation partner with roles the organization needs to staff during roll out. Roles we have:
- Project & Change Managers
- Business Analysts & Business consultants
- Data Leads & Consultants
- Test Leads & Consultants
We are not subject to another’s authority. We have strong knowledge about the HCM systems that matter such as Workday and SuccessFactors. And last but not least we guarantee success with our proven methodologies and Quality Assurance