RACI method made simpler – for use in Project Management

RACI  stands for Responsible, Accountable, Consulted and Informed. Sometimes it is also referred to as RASCI – where the additional S stands for Supportive.
Where:
Responsible – implies the person who “owns” the project.

Accountable – Person to whom R is accountable. He is normally the person who would sign off or approve the project or completion of tasks.
Supportive – Person who supports the tasks/project.
Consulted – Person who can be consulted or who has the required information to complete the work.
Informed – Person who just needs to be kept informed about the work/task or project.

It is a simple yet powerful tool used to help clearly assign the roles of the resources working in a project.

It is normally implemented using a RACI chart or RACI Matrix as shown below:

 

Steps involved are:
1) List all the activities across the rows of the chart and the resource names across the columns.
2) Identify the R, A, C, I and S for each task.
3) Thumb rule is to ensure that each task has “only one” Responsible person.
4) Review the RACI chart and ensure that there are no overlaps or gaps.
Usage:
The requirement of RACI is in ensuring that all resources have proper roles assigned with no overlaps and gaps. It can also help in assigning tasks to each resource during estimation/ scheduling and efficient scheduling of tasks. As in my previous article on 5 quick tips for successful projects, it is important to have clear ownership of project at every level and no wonder a simple method like RACI can be if immense use.

5 Quick Tips to successful projects

1) Get early visibility of the project and ensure that sponsors, stakeholders are all aligned.

2) Ensure that project plans have clear ownership.

3) Ensure that communication plan is set-up much ahead during the initiation stage.

4) Get early visibility of high level risks right from the initiation stage, and manage risks throughout the project life cycle.

5) Adhere to appropriate process for the given project.

Project Management Tips for Mobile Application Development

Project Management core processes and Knowledge Areas remain fundamentally same; however, the way it is applied in different industries or scenarios varies. Truly, the PMBOK mentions about tailoring the project management processes based on the project requirement.
Here, I have put across some points to help manage mobile application development based projects. One may think that more or less it would be similar to the project life cycle for IT software, but there are differences that one must know. In fact, even within the IT software industry, projects are managed in different ways based on the size and complexity of the IT project.

If we look at the overall project life cycle, it all looks similar in the sense that it involves the 5 core processes of initiating, planning, executing, monitoring & controlling, closing. One needs to apply the various knowledge areas in varying degree to ensure that the Mobile Application Development project is executed successfully. However, there are differences that need to be looked into.

Let us first understand some of the key features of Mobile Application Development.
Mobile application development is the next generation technology driven business. Mobile application development differs from PC software development. Device compatibility is a major pointer here. Also, based on the Operating system such as Symbian, Android, Java ME, or Windows Mobile, one need to use appropriate coding language, environment and testing in simulation environment to ensure that the application developed caters to the appropriate OS and device. See, link: http://en.wikipedia.org/wiki/Mobile_application_development for in depth detail. 

So, obviously another aspect will be the GUI that too will vary to some extent based on the mobile device. The Quality testing done for mobiles also varies. 

Testing is done for the device itself to ensure that basic functionalities such as Charging, Network etc are working fine. The testing of application developed itself is conducted separately. Finally, once all this is working fine, the device is finally tested to ensure that local Govt laws and regulations are adhered to. 

So, here are some practical tips to manage mobile application based projects:
1) SCOPE: Ensure that the scope mentions clearly about the mobile device compatibility and the OS, Coding language, environment etc very clearly. Specifically, which mobile devices are NOT covered in the project will be very useful. Ensure that the scope does not affect external environmental factors such as Govt laws, regulations etc.
 

2) INTEGRATED CHANGE CONTROL: This is the key to every project. Hence, an insight on how this area is impacted is important to know. Ensure that, the changes expected by the client are recorded in detail and discussed and thrashed out to the minutest detail. This is to ensure that the lack of technical knowledge at the client end should not create scope creep or even changes that are beyond the scope of the project. Especially due to the mobile device and OS compatibility.

3) TIME, COST and EVM: Ensure that all stake holders are aware of the exact status of the project. This is more important especially because we are dealing with changes in a relatively new industry.

4) COMMUNICATION: The communication plan should be published early in the project and with clear escalation path. The project status and reports should be communicated regularly to all stakeholders especially the client. If there are any technical changes (e.g., change in GUI or in the business logic) and calls for more time, it should be clearly communicated. More so, it is important to have face to face meeting with the client to help him understand the technicalities and complexities involved due to the changes expected.

5) RISK: Last, but not the least. Needless to say, apart from the risks that would arise due to scope creeps, time delays, etc, the key would be to keep a watch on all the technical changes. Especially if the changes alter the business logic or GUI. If the requirement is to support a few more new mobile devices that entered the market that was not anticipated earlier, it may require a complete new project in its own. Especially due to the technical limitations mentioned above. The change in govt laws or regulations can play havoc if the mobile is shipped without conforming to these. This too should be put in the watch list and taken up as a priority when the need arises.

Finally, all this ties up together to manage the Change Control effectively. Especially because all stakeholders are new to a relatively new emerging technology driven industry.

Practical Tips for Effective Schedule Management

Sometimes back, I had posed a question on effective scheduling, I was overwhelmed with the amount and quality of response I got. No wonder, we all look forward to the idea of having an effective time management in place.
I thought this as a good idea and opportunity to list all the practical tips that I received by other project manager’s wisdom and my own experience… I believe this will help a greater audience in managing their project schedule in a better way.

First and foremost, ensure that you warm up with the most basic things in place…. The scope…
 

WARM UP:
• Don't start schedule creation before you understand the scope of the project. It is key to understand the overall goal of the project; and for this it is important to understand the overall product or service; then drill down to the goal of the project and finally to the scope of the project.
• From the scope comes the WBS. So, having done the homework saves a lot of time and energy in breaking the WBS into activities.
• Engage the stakeholders and ensure a sense of ownership for plans. Never lose sight of the fact that you are managing people more than specific projects.
• Log all assumptions. Also, you should make sure that you have assessed all risks and factor them while developing the overall schedule. 

PLANNING PHASE:
DEFINING ACTIVITIES, SEQUENCING ACTIVITIES & ESTIMATING ACTIVITY DURATIONS:

 
• From the scope, include ALL deliverables. If there are any submittals, ensure they are part of the activities…. these can be a bear! They need to be tracked very well in both the schedule and also in some other system (e.g., spreadsheet, etc).
• Get the best duration estimates you can based on optimistic, most likely, and pessimistic. Then find out why there is a difference between most likely and pessimistic. What problems are they anticipating? Add those to the rest of your identified risks and perform a good risk analysis process. Add an appropriate contingency of time to your schedule estimate to establish the schedule baseline. Otherwise it is not realistic.
• Always buffer your deadlines at every stage to under promise and over deliver. Learn from your own AND others mistakes.
• Avoid hard dates. In most of the scheduling techniques, the instructors emphasize that the only hard date should be the start date of the project. The rest should flow through dependencies. So, use constraints sparingly and only to reflect TRUE constraints
 

ESTIMATING RESOURCE DURATIONS:
• Make sure you assign responsibility to a single person at every point of the projects progress. The worst thing during execution is when no one takes responsibility for a mistake.
• How much of each resource can be allocated to the project. If your company enters time in time tracker, you can do an analysis. In a particular organization, for example, people work max. 70% on projects (rest is support and administrative), so make sure you put this % for each resource in the resources sheet (if you use MS Project) and make sure you don't assign resources to more than this.
• Put time off in the calendar. Add Holidays to the global calendar, and then each person's vacation.
• Any standards in terms of plans should be considered and incorporated in to the project schedule, ensuring consistency across plans. For example, the use of the same project calendar is vital.
• Assign lower allocation for the best resource on the project. Chances are they will be pulled into other activities or projects, and this way you reduce the risk.
• Does the team work 7, 7.5 or 8 hrs/ day? This is important, especially on a long project, so make sure you configure your project file from get going.
 

CREATING SCHEDULE (BASELINE):
• Before baselining the schedule, ensure you iterate over the plan for any missed item/ points. Ponder over the points below before you baseline and submit the schedule for tracking the project.
• Tasks with an estimate of more than 80 hrs should be broken down until you get to 8 hrs or less. From my experience, you lose control over progress if task is too big. Normal thumb rule adopted is the 8:80 rule. Task should not be less than 8 hours or more than 80 hours
• Take into account time for customer feedback and revisions that are needed
• Be realistic about deadlines.
• Coming back to WBS - The WBS establishes a way to separate the job down into discrete scopes of work to collect both cost and schedule information to be able to establish performance. While that may sound like too much work and a bit much for this job, it is the right way to be moving towards.
• The most important one: Identifying and concentrating on the "critical path" activity is crucial. If that one is not taken care of, all you other schedule is negatively affected.
• Finally, make sure that you capture any assumptions that you've made in building the schedule so that you can refer to these at a later time. Best to keep these within an assumptions log, in much the same way as you would capture your risks.

• A final check list could be:
* Are tasks defined as actions (Write Report; Install Widget; etc).
* When linking tasks, ask yourself, "In order to do X, what _must_ we have completed before we start." These are your predecessors.
* Are all tasks linked to the goal (predecessor / successor relationships)? If not, then there is missing logic.
* Assign a responsible role (or person) to each task: who is responsible for ensuring the task is done? May not be the specific person doing the work.
* You can also prefer the Critical Chain Project Management perspective where execution is geared toward single-tasking and people are encouraged to finish as quickly their task as possible (not on a date). And there are strategic buffers placed to protect the overall project.

MONITORING & CONTROLLING SCHEDULE:
• How often should the schedule be updated? General Rule … Don’t allow more than 5% of the schedule pass without an update. Less time is even better, say 2.5% or less. So, if it is 12 months – times .05 (5%) = 0.6 months or about every 2 weeks.
Remember the following:
1. Remember that you are scheduling people, not projects - People have a way of making the neatest schedules into an untidy mess. Prepare for this even if it means scattering fake tasks at intervals in the schedule so that you have unused time which can be applied to the slow bits, and help you keep the promised delivery date. See Critical Chain for a formal discussion of this.
2. Remember that you are scheduling people, not projects - And plan to review and adjust the schedule regularly to account for all the people issues that will arise.
3. Again, Remember that you are scheduling people, not projects- So do communicate regularly with the people whose work you have scheduled and do communicate to them honestly about the true urgency of their scheduled tasks. Some people will do all they can to help you. Others will delight in making your project fail. You need to know who you are working with.