Challenges faced in managing projects using the traditional method
The first step in developing software is gathering requirements. The developers ensure that the scope of the requirements is specified clearly. On the other hand, users tend to ask for everything, whether required or not, so that they get the best deal from the developers.
The developers will use the scope to estimate the time to develop and cost. The users will negotiate for the best price with the developers until an agreement is reached.
The problem begins when users want to add a requirement. The developers will inform that it is a request for change, but the users will argue that it is not a new requirement. This happens for the following reasons;
Users may have overlooked the requirement. Obviously, they may not remember everything during the time of writing the specification. They may realize it only later when they come across it while working on a real case.
Though it may be a new requirement the users will try to justify that it was specified for fear that their managers may penalize them, since it may increase the budget.
The developers may have interpreted it wrongly. The developers are technical persons and hence may not have sufficient domain knowledge to interpret correctly. For example, in insurance when age is used, it can be the nearest age, age last birthday, or age next birthday. The users may not specify the right age to use. They may take it for granted. Whereas a technical person will tend to use the nearest age as default. On delivering they may end up with an argument if the right age is not delivered.
To protect themselves the developers may request test cases, but the users may not be able to write the test cases appropriately. The users may also refuse to write the test cases for fear that they will be pointed out when things do not work accordingly.
Projects may be delayed due to the following reasons;
The gathering and specifying requirements may take a longer time than expected.
The time may have been estimated wrongly by the developers
The resources required to develop may not have been estimated correctly.
The resource may not have the expected capability after recruiting.
Key persons may resign suddenly on either side
The users may not involve in the project as required because they have their day-to-day operations to handle and the additional project work may be stressful.
The project may not be managed appropriately, or the project manager may resign halfway.
When a project is delivered after a long time it may not meet the expectation because;
The deliverables may not have been delivered as expected.
The users who wrote the specifications may not be present to verify the deliverables.
New users recruited may not agree with the specification of the earlier user, because, the ‘new broom may try to sweep clean.
The quality of the deliverables may be poor.
The users may realize that some features were left out in the specification only during the acceptance test.
Business changes may happen while waiting for the project to be completed.
Technical changes can also happen.
The customers of the users may be demanding for better user experience after delivery.
Working on change requests may take a longer time. Some users may not accept the software delivered initially and introduce the changes as and when delivered. They may insist that the changes must be introduced before they accept the whole software. This will increase the tension and delay the project further.
Sometimes the developers suffer without receiving payments on time.
All of the key issues mentioned above happen on long projects when users witness the deliverables at the end of the project. The experience learned is; that when the deliverables of software projects are not delivered within three to six months the acceptance of the deliverables suffers. If the deliverables of a project can be delivered at intervals the users will be happier to enjoy the results faster, deliverables often meet the expectation because developers, users, and customers collaborate. More payment milestones make users happy to pay for the work done and the developers may not suffer delays in payments.
We found that most of the issues discussed above were resolved when agile project management was used.
Why agile project management
Instead of witnessing the deliverables of a project at the end of a project, quick and smaller workable deliverables (minimum viable product – MVP) that add value to a business delivered along the journey of the project will increase the satisfaction of the stakeholders of the project. The smaller deliverables can be prioritized according to value, urgency, and low-lying benefits. This process of working on incremental successes of a project is achieved through agile project management. Agile project management will;
Deploy a project faster
Bring people to collaborate together through stand-up meetings of stakeholders of the project frequently and achieve quick MVP.
Make the top management happy to realize the project in incremental steps
Make customers happy too by adding value to their expectations with incremental improvements
Allow flexibility for changes for the next steps, if unexpected events happen along the way, or a mistake was made in the previous steps, or a requirement was missed out in the earlier steps
Help people balance between day-to-day operational work and project work
Manage risks better
Preparing the mindset of people involved in agile project management
During the entrepreneurial stage of an organization, the people in the organization are charged up to bring the idea to fruition with minimum risk. In this context people are innovative, proactive, empowered, collaborative, and embracive in multi-tasking.
As the organization matures processes and workflows are implemented to manage the business. In this environment, people tend to be opportunistic, reactive, process-oriented, cooperative, and stick to task boundaries.
Agility in the entrepreneurial stage is extremely important, but members of the team may not respect agile project management because people brush off everything else except to get the idea working. Due to anxiety, unfamiliarity, and uncertainty during the forming and storming phases of project management of bringing the people to work together, a very strong leader is necessary to support agile project management.
Agility in matured stage has its own challenges in making function-focused people work with processes cutting across functions in an incremental manner. During the forming and storming phases of a project, people must be continuously reminded of the benefits of implementing processes and enriching their careers by cutting down inefficient and mundane tasks and elevating their careers with value-added tasks.
Challenges of agile project management
Agile project management is changing the mindset of people who are used to working with projects managed in a traditional way. Wise people say; “If you want to create an enemy, introduce a change.” Therefore, it is not going to be easy for Project Managers to implement agile project management.
Some of the conflicting principles that make it difficult for people to accept agile project management are as follows;
Requirements are not specified in detail in agile project management because the Users may not know the exact requirements to be specified. Only the essential requirement for a deliverable or a sub-set of a deliverable is specified. They are called user stories. The details of the user stories are decided and approved after experimenting with quick prototypes.
The three elements of project management; scope, time, and cost are not elaborated for the whole project. This will make it difficult for the sponsors to justify the ROI of the project.
People may know what and why a particular sub-set of a project is built, but may not be aware of how all the sub-sets will be integrated to achieve the complete value of the project.
Agile Project Managers can consider the following tips to sail through the journey of agile project management:
Train the stakeholders of the project on the benefits of agile project deployment.
Tell them that they will not be pointed out if they overlooked to include some important features in the requirement specifications. They will not be penalized for forgetting to inform any changes to the requirements that happen over time. They will have enough opportunity to change the requirements after working on real features delivered in the form of prototypes.
Inform people that they need not go through the drudgery and frustration of project deliverable testing, and day-to-day operational work happening together if the deliverables are handed over at the end of the project. Since the project deliverables are delivered in incremental stages the project work is lesser and will not burden the people over their day-to-day operations. Further, the stakeholders will be motivated to work on the prototype, which is the reality of the idea they conceived at the beginning of the sub-set of the project. The quality of deliverables is also assured with people having more time and involvement for incremental testing.
All stakeholders must involve while interacting, experimenting, iterating, and approving to work on the deliverables of the sub-sets of a project. They must trust each other, and be open and transparent.
2-rolling weeks
A sample is added below for appreciation.
Sub-set deliverables
Whether sub-set deliverables of a project are true to the definition of the agile project (sprint) or not, the sub-set deliverables can be managed with 2-rolling weeks of project management.
A sprint or sub-set of a deliverable can be stated in the first column of a spreadsheet. A project can have multiple sub-set deliverables.
Activities and Tasks of sub-set deliverables
The activities related to the sub-set deliverables can be stated in the second column. The tasks can be stated in the 3rd column of the spreadsheet. The owners can be stated in the 4th column against the respective tasks.
The activities of all sub-set deliverables, related activities, and tasks can be done for the entire project. If the tasks are not identified yet they can be skipped. Even activities can be skipped if not established yet. This will give a feel and estimate of the entire project deliverables, scope, time, and cost.
The ‘what’ and ‘why’ of all the sub-set deliverables and their relationships to fulfill the entire project can also be appreciated.
Rolling 2-weeks
To have a focus on the current one week of activities/tasks and not worrying about activities/tasks beyond 2 weeks the rolling 2-weeks will help. Starting from the 1st week of action focus on the 1st and 2nd week. The 1st week will have definite activities/tasks. The 2nd week will have reasonable activities/tasks. While working through the 1st week the 2nd week's activities/tasks will be concretized. Any activities/tasks missed or extended in the 1st week are added to the 2nd week. While working on the 2nd week the 3rd week's activities/tasks are focused. So, the rolling weeks go by 1st and 2nd for the 1st week, 2nd and 3rd for the 2nd week, 3rd and 4th for the 3rd week, and so on.
The success of focus depends on the commitment of the stakeholders to make sure that whatever activities/tasks are confirmed for a week must be completed by that week.
Stand-up meeting
Daily or agreed days in a week and time shall be fixed to meet to interact quickly on the activities/tasks accomplished and hurdles.
This activity aligns stakeholders, including customers, and enforces collaboration.
Conclusion
When a project is planned, scoped, and specified in detail upfront, it is very likely that it may not be delivered as visioned. If the deliverables of a project can be broken into phases with a direction to reach the destination, but concentrated phase by phase, the probability of success of the project is very high.
It does not matter whether one is strictly complying with methodologies. Methodologies are guidelines. Agile is sometimes referred to as mindset.
The training provided to the stakeholders should focus on the reasons behind the ‘rituals’ of methodologies. While ‘methodologies’ are important to secure a certificate, the reasons behind them and practical experience are important to implement a successful project on time, of quality, and within cost. Author K. Kuppusamy Founder of Aetins Malaysia