by Anita Potgieter, COO at FOXit
I have been implemented project management systems for some time. In my experience, at the majority of companies that have declared agile project management as their methodology of choice, the reality was that there was no processes in place, no controls, no structure… nothing!
The widely used Waterfall Methodology works well if your customer knows what he or she wants, but what happens if that is not the case? What happens if you think you understand what the customer wants, but when you have developed the system for months and finally get to a stage where you can demo something, it is not at all what the customer had in mind?
We all know how long it sometimes takes to gather requirements. We also know how long gathering requirements and getting client sign-off can delay the start of development.
What happens when you are half-way through the project and the client wants one specific portion of the system to function differently? One can argue that you can raise a scope change at this point and include it in the project scope – but what if the underlying architecture was not designed to cope with it?
Let us have a look at what Wikipedia says about Agile:
“Agile management or agile project management is an iterative method of determining requirements for engineering and information technology development projects in a highly flexible and interactive manner”
In my opinion, if used correctly, the iterative nature of agile suits the methodology required for managing software development projects. You still have to do proper and continuous planning though.
You can still have your process/requirements analysis workshop with the client – but not down to the detailed level. You can plan for a release and the first iteration, but from there, the team needs to continuously plan iteration by iteration in order to refine the scope of the next release in line with changing requirements.
Instead of the Project Manager being the interface between client and service provider, the team needs to get involved in these interactions because it is ultimately their responsibility to deliver what the client wants. Making the client part of the team will enhance the probability of delivering a desired product, but undocumented and rushed decisions should be looked out for as it will contribute to scope creep that all Project Managers love so much.
So if you keep on planning these iterations, should anything be documented and signed-off by the client, or do you just carry on hoping you’ll get it right at the end?
In my opinion, the following documents should at a minimum be created to have some form of control in place:
1. Important design and architectural elements
2. User stories
3. Acceptance tests
4. Project Schedule
In order to get a project schedule out, the functionality needs to be broken up into chunks and for each of these chunks, you should still:
1. Analyse and workshop the requirements
2. Design
3. Develop
4. Test
5. Deploy
The result is that the client will be able to see chunks being delivered on a regular basis instead of hoping that the service provider understood what they meant. Interdependencies between the different chunks should be planned for as well, otherwise it will seem like the systems were just slapped together.
Control freaks will not like this way of working and if you are a traditional Project Manager, you will need to let go of the reigns. You can plan the high-level details of the system, but you will need to have a tool in place, like Team Foundation Server, that can integrate into Project Server where your schedule resides. This will allow the team to break down the high-level tasks in your schedule into the chunks they require to deliver in an agile way.
Daily scrums will alleviate the feeling of chaos and will enhance team communication, but someone still needs to follow-up and dish out tasks to team members that doesn’t have anything planned for the day – otherwise you will form part of a team that is proverbially failing to plan and inevitably planning to fail. Part of the daily scrums should be risk reviews which theoretically should improve risk identification than opposed to traditional Project Management where risks might only be identified upfront and during progress meetings.
It also calls for an improvising and problem-solving approach to managing the team as well as the project and if you are too set in your ways, this might not be something you should get involved in.
All-in-all, the sweet spot in my opinion here is planning accurately down to a level that is necessary for the current iteration, controlling and monitoring it tightly and closing it out when ready.
How is that for controlling the chaos?
FOXit (Pty) LTD. is a South African established International provider of solutions, service and support focused on Project and Portfolio Management (PPM) in business.
The company specialises in:
• Project & Portfolio Management Solutions (the design, implementation, consultation and support of the automation of project and portfolio management processes and solutions)
• Business Productivity Solution
• Mining Solutions (specialist product and consulting services to South Africa’s mining industry and related industries
• Advanced Technology Solutions (consulting and implementation of world-class, leading-edge developed products and solutions)
Solutions are based on the Microsoft Business Productivity Stack.
The company continues to harness its expertise, experience and technology know-how to refine cloud-based PPM services to empower business across a number of industries.
It has unrivalled intellectual capital within an increasingly competitive market.
FOXit is Microsoft partner with Gold certification across numerous competencies within the Microsoft Partner Network, including Project and Portfolio Management, Portals and Collaboration and as an Independent Software Vendor (ISV).
The company also holds various Silver competencies in the Microsoft Partner Network.
The progressive, multi-dimensional service provider openly challenges the norms that define technology service acquisition and investment.
