Mapping Agile Project Management to phases of Traditional Project Management

In this article I am going to talk about how we could map agile concept in a traditional project management phases. This is highly useful when moving from traditional methods to agile. So first of all what are the phases of traditional project management.

Initiation: During the initiation phase even before getting the team and infrastructure, you need to get the business case ready. You need to convince the project board about the ROI. i.e. whether this project worth of investing money and knowledge. Once the project board is presented with what the project is going to do to the business and when they approves it, you can look into identifying the budget, the team, the infrastructure, etc.

Planning: In this phase we prepare the schedule, resource planning, preparation of the firm budget and a cash flow plan, resource plan, risk management plan, etc. Also we can finalize the team and the infrastructure required. You may want to plan for change control management, issue management, etc. as well.

Execution: So after all the planning is done we are ready to roll out with the execution. During this phase you need to monitor and control various activities such as development, testing, change control, release management, etc. and ensure that the team is on track and delivering the requirements according to the plan.

Closing: At the end of the project you need to package up everything and ship the product to the user. You also can allocate time for end user training, preparation of user manuals, UAT, etc.
I am sure that all the audience are aware of the activities in detail which are executed during these phases. Here I have given a brief description. What my goal here is to discuss how agility can be implemented on top of these phases.

This is what I do. For me we have to do initiation and planning up to some extent before beginning. Remember doing agile is not just starting with it. You need to do some preliminary planning first. This will totally depends on the nature of the project. If your company is focusing on software products you may have to have product road map with several releases during the year. So if you want to get some new features done and some long hanging bugs fixed then initiate an internal project. You may want to get the involvement of the product managers and convince them about the priorities that you have set. You can use the planning phase to carry out traditional PM work as mentioned above.

Apart from that I particularly think that these stages are important because you need to lay the base in order for the agile project to be success. Some of the key things that you need to get done during these stages are:

  • You need to identify the team. You need to get the best people onboard, because the individuals need to ride along with rapid pace of the project.
  • The infrastructure. You need to get all the basic infrastructure ready for the project, such as setting up development environment, the QA environments, Continuous Integration setup, infrastructure for automated testing, etc.
  • It is equally important that you set up a release management strategy that can keep up to the pace of continuous releases.
  • Then write some good chunk of user stories for the project. If it is a large project write user stories that fill up 2 to 3 months of development work.
  • Some mechanisms to control the changes, because by definition agile encourage change. So you need to make sure that you do not end up in a Scope Creep situation.
  • Also use this time to educate the end users about the agile process and the importance of their participation.
  • The best part comes next. Running the project with Agile. Now you have set you foundation to start the project and you can kick off. Once you start there is no turning back. So get the preliminary work done.

    With agile planning, execution and closing phases are repeated at each iteration. i.e. we do sprint planning, executing the plan and close the iteration with client demo and the sprint retrospective. Also when we close the project, we should have a final closing phase to complete any user manuals, final UAT, any further trainings. Actually you don’t have to do a final UAT if you would do a UAT session at the end of each release.
    I think the best practice is to plan releases. Each of these releases may contain 3 to 4 sprints. Do not exceed more than that. At the end of each release plan for some UAT session, this way you will have a clear picture on what you need to add to the next release. So your estimations will be more accurate and above all the user is experiencing the system at early stages so when it comes to the last closing phase you don’t have to have trainings or any additional UAT sessions, because the user is already know and accepted your software during execution phase itself. So plan, and keep in track of where you and your team are heading.

    Remember what Abraham Lincoln said: “Give me six hours to chop down a tree, I will spend first four hours sharpening the axe”. The bottom line is plan and lay the foundation, with that your execution will be eventually successful.


    One comment

    Leave a Reply

    Fill in your details below or click an icon to log in: Logo

    You are commenting using your account. Log Out /  Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )


    Connecting to %s