CASE STUDY:

You work for a medium sized software solutions provider called FreshLime Software. And your company specializes in both greenfield new project development and maintenance contract projects for other large companies.

Your Client for this project is a large digital education provider called EduTech Academy Incorporated. They have been using a client server based software from the last 15 years, catering to their own corporate Fortune 500 customers. And now, they want to shift over to an internet based web application - and that is where you and your company comes in.

You are a new Project Manager, assigned to this project. A contract has already been signed by the sales team and you have a copy of this contract.

The Project Kick-Off Meeting is the first meeting between the project team and the client of the project.

As the Project Manager, you will be expected to set up the date, set the agenda and lead the meeting. You would conduct the kick-off meeting after some sort of a contract has been signed and put in place if it is an external client - or if it is an internal client, you would have some email or documentation in place.

In this lesson, we will see why this meeting is important and I will show you an agenda that you can use - and also you can find an downloadable template!

The kick-off meeting is very important because it will lay the framework on how the project will be executed. You will establish what your team is expected to accomplish in the project, how you will achieve it and other protocols to be followed during the course of the project.

The kick-off meeting should touch upon details of the Project, the Process that will be used and the People on both sides of the project. You will invite the key stakeholders of the client's side and from your own company.

Let us see a sample agenda for the kick-off meeting.

The first thing on the agenda would be the high level scope of the project: for example "the development of an online learning web application for EduTech Academy as detailed in the contract <ref>". You can also put in a reference to the contract document at this place.

The next thing on the agenda will be the high level schedule and deliverables. The catch at this point is that you will not know the exact dates - as you have not yet started detailed planning. All that you are expected to do is to list out the major milestones and tentative dates. You are allowed to be a little vague - for example "2nd week of October" or "end-of October". However, you can mention that the actual dates will be shared on a particular date. For example you can say, "by end of next week, I will email everyone the actual dates for project deliverables".

The high level assumptions and risks are stated next. For example, suppose you are relying on the existence of a certain open source software component that can reduce work and cost and the current schedules are based on the fact - this is the right time to re-iterate this fact - and also mention the consequences of this assumption.

The next item is Receivables from the client - this is a critical point that is often left out by Project Managers. Almost always with external projects - there will be somethings that you have to collect from your client's - for example access to their legacy software in order to study existing design, or some technical documents from their technical team, or a list of non-functional requirements etc. At this point, you will list out the receivables and ask for tentative dates when you can expect to receive them.

Next, you will introduce key team members. Specifically, you will like to introduce the team members who will likely interact with the client - for example, the Architect, Technical lead, User experience lead and Quality lead. As per your specific project - you will choose who will interact and introduce them.

Communications plan is basically how you as the project manager will report on the progress to the client - whether weekly, fortnightly etc., what is the frequency of such reports and what is format and what is the escalation mechanism?

The escalation mechanism is triggered when the client feels apprehensive about something in the project and would like to talk to somebody more senior than you, the project manager. So you will share the email and contact numbers of your reporting manager - and if they are already on the meeting, introduce them.

The last thing on the agenda is an Open House - when anyone can ask any questions or bring up any points they feel has been missing in the agenda and needs to be addressed.

What happens after the meeting?

You can share the meeting slides, minutes of the meeting and also this is an opportunity to make any corrections or updates.

So, in conclusion, you will use the kick-off meeting to set a baseline for your project, create confidence with the client that the project is in YOUR capable hands and then galvanize both teams. So, make good use of the project kick-off meeting!

This is a real life example of a detailed Kick Off Meeting presentation. Additionally, you can download the PPT file itself as a template - and customize it freely for your own project.

A Software Requirements Specifications (SRS) document is a description of the software project that you as the Project Manager will be responsible for developing.

It will describe the complete functional and non-functional requirements of the application. Additionally, it will list out all the assumptions, dependencies and all also detail out the environment in which the software will be expected to function during its lifetime.
---
I have provided a SRS template in the download section of this course - and you can freely use it for your own purposes.

The SRS is like a of contract with your client, whether external or internal to your organization. It is also the base scope document for your own team - and software design and development will use the SRS document to proceed.

Unique challenges when writing the SRS:

a. Multiple stakeholders will read the document - and the document should be understandable to all. The audience will include the Business folks both from the client and internal to your company. Similarly, your own technical team will also use the SRS as a baseline for starting design. So, the document should be more functional and easy to read rather than a technical document.

b. Inevitably, there will be changes to the functional requirements of the application - and so every time the SRS will have to be changed accordingly. It is very common for Customers to back-and-forth on some features. Changes may happen faster than the time you have to update the document itself. Every version of the earlier SRS should also be available for review with the customer. So, a very good change control mechanism should be in place.

c. There will be a lot of unknowns before the design phase - when the SRS is written. These unknowns have to be clearly marked out and communicated to all parties. As soon as something becomes more clear, it has to go into the SRS diligently.

So, all-in-all the SRS is a LIVE document and will have to be updated, reviewed and approved several times over the course of any project. Whether you will preserve a formal document or keep it informal is your decision in line with your company's expectations.

In conclusion, the Project Manager will need to have an iron grip on the SRS document - ensuring that the document is readable, changing the SRS document as often as required to ensure that it actually reflects the state of the requirements as understood by the customer. Furthermore, the document itself will have to be under change control - to ensure that requirement changes can be traced back over time.

What is the Work Breakdown Structure (WBS)?
WBS is the hierarchical and iterative decomposition of the complete work of the project into manageable work packages. Once the scope of the project has been defined the Project manager with the assistance of the team has to break up the scope iteratively into smaller and smaller pieces of work.

Why is creating the WBS important?
The WBS ensures 2 things - firstly 100% of the scope is addressed - and secondly nothing other than the scope is addressed.

The vast majority of projects that fail - do so because the scope and requirements are not clear. The use of the WBS is the single most important thing you can do to ensure that a project comes in on time, within budget, and with the quality and functions that were expected. Do not skip this step.

Show me a sample of the WBS:
In this sample you see the first and the second iteration of the WBS. Initially, we have broken down according to the phases that will occur on the project - this is logical to begin with. You might also notice that Waterfall methodology is used here. However, any other methodology you were using, the WBS process does not change.

In the second iteration, the one more level of breaking up is done. There are some simple rules to breaking down the work - we will look at them shortly.

Think of your WBS as an outline of the work, designed in a tree diagram. The lowest level of the WBS contains the work packages—that is, the tasks and actions to complete the work. You can create this diagram using Microsoft Office Excel, Visio, or any other tools, or you can draw it on a whiteboard. No matter how you choose to build it, creating a WBS is a project management best practice and an opportunity to
brainstorm and organize before creating the actual schedule.

You can download a simple WBS sample from this lesson's download section.

Who creates the WBS?
You as the project manager own the WBS. Typically, the first and second level of the WBS is created by the Project Manager. Subsequent detailing needs to be done by the person best suited to do it - in this case, the Architect, Technical Lead, Creative lead and the Quality lead.

When should you create the WBS?
You should create the WBS after the scope has been defined and definitely BEFORE creating the project schedule.

In this lesson, we have seen what the WBS is, why it is important, who should create it, and when it is to be created. In many cases, the first 2 or 3 levels of a WBS can and will be re-used in an organization. So it is great practice to create one for yourself and keep using it as a template.

In this lesson, we will see the 10 most important rules - or tips and pitfalls to creating the WBS. There is only one way to become good at creating WBS - and that is to practice and practice. This lesson will teach you some very important guidelines on how to create a great WBS.

Rule 1. create WBS with your team - not alone - as you want their complete involvement and understanding
Involve your team in the planning stage of the project. Build the WBS interactively by first defining what deliverables need to be created. You will have a more complete WBS and a team that understands what they need to do.

Rule 2. WBS should have atleast 3 levels - highest level is the project itself
For medium to large projects you might have several levels more - depending upon both the complexity and the size of the components.

Rule 3. Don't confuse WBS to a task
WBS is a work component that will be decomposed into tasks. This is also a pitfall that awaits many project managers. For example the "Registration Page" is a WBS item - but not "Write bad password lockout logic". The latter is a task and you should not look at tasks while creating WBS.

Rule 4. Naming Convention: Name a WBS item as a noun (and not a verb)
This makes it very easy to identify WBS items and tasks on the project schedule in the future. Again taking the same example - "Registration Page" is a noun - but "Write bad password lockout logic" uses a verb at the beginning.

Rule 5. The WBS lists your work breakdown, the task list is the breakdown of the WBS into actions
This is almost a repeat - but is a very frequent pitfall - to elaborate on this, tasks belong to the Project Schedule - don't do task breakdown while doing the WBS. Schedule comes AFTER the wbs.

Rule 6. The 100% Rule:
Each lower level of decomposition must represent all of the work of the higher-level element; conversely, all higher-level scope must be reflected in one of the lower-level elements. This is called the 100% rule, which ensures that all of the scope has been captured and that nothing unnecessary is included.

Rule 7. WBS is almost never complete or right in the first iteration.
The more you learn about your project - the more you will alter your WBS. This is absolutely great - and you should be prepared for this.

Rule 8. Tasks have to be small enough to be assigned to individual resources - NOT the WBS
Please read this carefully. You should decompose WBS items only enough that they make logical sense as a component and not more than that.

Rule 9. The lowest level of the WBS—the work package — will be represented by a summary task on your Project plan.
This is a great tip especially if you are going to use a tool such as Microsoft Project to create your Project Schedule in the next step. Each of your WBS work packages should become a summary task. Summary tasks are collections of logically grouped tasks.

Rule 10. The 8/80 Rule:
This is the single most asked question everywhere about WBS decomposition: "When should I stop?" The answer to this given in a thumb rule: the 8/80 rule says that "All work packages should be greater than 8 hours and lesser than 80 hours". This should give you a fair indication of when you can stop working on the WBS.

So, in this lesson, we have seen 10 rules or tips and pitfalls of how to create the WBS - and also on when to stop. The next step after WBS is to create the project schedule. Please ask your questions in the comments section - share your own WBS with the rest of the learners on this course. It is very helpful if you share and also see the WBS that others are creating to improve your skills on the WBS.

On our journey to create a great project schedule, the next thing we need to do - is to decompose the WBS further to Tasks. If your WBS has achieved a sufficient level of maturity - then before starting tasks - we would have accomplished the 100% rule on the WBS. If you are not familiar with this rule, have a quick look at my lesson on the "10 Golden rules to WBS creation".

OK, so every WBS element should be broken into tasks.

Now let me first answer a very important question: why should I NOT create tasks along with the WBS? This is because you do not want to mix the requirements with the implementation details. WBS represents the requirements. Tasks represent the implementation. There may any number of ways to implement the same requirement. And we do not want pre-maturely think about implementation.

And that is the reason why we do not want to think about tasks while still detailing the WBS.

Returning back, let us define tasks - and then later we will see some examples.

A common definition is: "a task is an activity that needs to be accomplished within a defined period of time or by a deadline to work towards work-related goals".

A task is something that needs to be performed - and we should at the very minimum have some idea on what duration the task might take or by some time limit when the task needs to be completed.

Let us look at an example where tasks have been detailed out. On the screen, you can see a project schedule that has been derived from a WBS.

The lines in bold are actually WBS items and their subcomponents are actual tasks that need to be performed on the project. You can see that there are many other things associated with tasks and we will look at them in much greater depth in the next lesson.

In practice, it might take several iterations before this level of detail is achieved while you are creating a task list - and this is perfectly fine and is a very good practice to do multiple iterations in task detailing.

Now, let us look at the responsibility assignment matrix for building a task list.

It is ideal that a senior technical team member actually builds most of the implementation details while building the project's task list. If you are a technical project manager - then this can very well be you.

The complete accountability for the task list (and consequently the complete project schedule) - is with you the project manager.

Relevant subject matter experts and technical experts should be consulted and asked to review the task breakdowns - this is fantastic best practice and I highly recommend it.

Finally, after you create the task breakdown, you should consider informing relevant stakeholders such as your boss.

So, in conclusion for this lesson, we have understood what tasks are and also seen a formal definition of a project task. Then we have learnt how to progress from WBS to tasks. We have seen the best practices with a responsibility matrix for project task breakdown.

In the next lesson we will go fully indepth in our understanding of tasks.

On our journey to create a great project schedule, the next thing we need to do - is to decompose the WBS further to Tasks. If your WBS has achieved a sufficient level of maturity - then before starting tasks - we would have accomplished the 100% rule on the WBS. If you are not familiar with this rule, have a quick look at my lesson on the "10 Golden rules to WBS creation".

OK, so every WBS element should be broken into tasks.

Now let me first answer a very important question: why should I NOT create tasks along with the WBS? This is because you do not want to mix the requirements with the implementation details. WBS represents the requirements. Tasks represent the implementation. There may any number of ways to implement the same requirement. And we do not want pre-maturely think about implementation.

And that is the reason why we do not want to think about tasks while still detailing the WBS.

Returning back, let us define tasks - and then later we will see some examples.

A common definition is: "a task is an activity that needs to be accomplished within a defined period of time or by a deadline to work towards work-related goals".

A task is something that needs to be performed - and we should at the very minimum have some idea on what duration the task might take or by some time limit when the task needs to be completed.

Let us look at an example where tasks have been detailed out. On the screen, you can see a project schedule that has been derived from a WBS.

The lines in bold are actually WBS items and their subcomponents are actual tasks that need to be performed on the project. You can see that there are many other things associated with tasks and we will look at them in much greater depth in the next lesson.

In practice, it might take several iterations before this level of detail is achieved while you are creating a task list - and this is perfectly fine and is a very good practice to do multiple iterations in task detailing.

Now, let us look at the responsibility assignment matrix for building a task list.

It is ideal that a senior technical team member actually builds most of the implementation details while building the project's task list. If you are a technical project manager - then this can very well be you.

The complete accountability for the task list (and consequently the complete project schedule) - is with you the project manager.

Relevant subject matter experts and technical experts should be consulted and asked to review the task breakdowns - this is fantastic best practice and I highly recommend it.

Finally, after you create the task breakdown, you should consider informing relevant stakeholders such as your boss.

So, in conclusion for this lesson, we have understood what tasks are and also seen a formal definition of a project task. Then we have learnt how to progress from WBS to tasks. We have seen the best practices with a responsibility matrix for project task breakdown.

In the next lesson we will go fully indepth in our understanding of tasks.

The final step after every phase of a project, is to subject it to review and get a signoff from an appropriate stakeholder. For example, if you have finished creating the Software Requirements Specification you will definitely want to get it formally signed off from the customer of the project - whether it is your own boss or an external customer.

What will happen without a formal review and signoff process on your project? Let us look at some altogether common problems that will occur without a formal signoff process.

1. Scope Creep - more features keep getting added to the original scope. The most dangerous aspect of this is that every incremental change appears trivial in comparison to the scope of the whole project - atleast to your customer or the boss. If you don't manage this with correctly, it can spiral quickly out of control.

If you have a documented and signed off requirements - you are in a position to say - "Sure, this new feature can be added - but it will cost more time and money".

Even swapping out a feature and replacing it with something new - will often cost extra time and money - as you will have to expense the design time.

2. Disputes. In the real world where we execute projects, people change jobs, old conversations are forgotten or sometimes business requirements will also change.

Imagine a situation, where a customer says after a year of development - "This is not what we asked for" - or "I don't remember asking for that feature". Unfortunately, these situations are all too very common. If you do not have a written and signed-off document to fall back on you are in a very tough situation.

3. Features getting added as "bugs". When it is time to handover and get closure on a project - many bugs will start getting reported by the customer about missing features. Again, this is a situation where having a detailed document signoff will prove its weight in gold. This is yet another form of scope creep.

So far, we saw what difficulties might happen if you do not have the base documents in writing and signed off. Let us look at some best practices on getting a signoff from the customer.

a. Best is to start at the very beginning. The first step is for the business work contract to clearly state the signoff process that will be followed. It will be good to mention that you will allow 2 review cycles and if no review comments are received after, say a week - the document will be considered approved and signed off.

b. Absolutely get the document internally reviewed by someone suitable inside your own organization before shooting it off to the customer. From simple typos to other major faux pas can be avoided if you do this step. This is also a clever way of getting commitment from your own boss and other seniors.

c. Always allow 3-5 days for the customer to review your documents and allow for comments and suggestions. In your email, please mention this time and a cutoff time by when you expect the review comments OR the formal signoff.

d. Learn clearly what the accepted approval mechanism is in your organization. For example, will the document have to be physically signed with ink? Or an email confirmation is OK? Many companies today work with any form of electronic confirmation for example even an outlook voting signoff is acceptable. Check with your legal folks if necessary - and use the most innovative and least painful method for the customer.

Finally, let us look at some common PITFALLS while going for signoffs - as committed by Project Managers:

a. Lack of transparency on the specifications and design. You might think it is safer to keep some aspects as vague as possible. Example, you might not specify a number for the pageload time of a web application. If you do this, remember the same thing might come back to bite you at the end - where a customer says "If Google can load a page in a millisecond - why can't you?"

This problem is most common for the non-functional requirements of a project.

b. Half-commitments. You might be tempted to please the customer by promising to deliver some feature "IF" you have the time left over or some budget left over. The problem with this is that most often, that time will never be left over and you will have a displeased customer. Because when you say "if" - it will always be heard as "definitely".

In this lesson we have seen what signoffs are, why they are important, what bad things may happen if you do not get timely signoff on your base documents - and finally the common pitfalls that are present while getting signoffs on your documents.

In order to know how your project is progressing, you will need to collect work progress information from all of your team members periodically. Once you collect this information, you can then update all of that into your project plan and you will have an up-to-date project status.

Let us first see how to collect project status information from your team members. You will have to establish a few things with your team on how this is done:
a. The frequency: daily (as in agile teams) or weekly - which is more common. Whatever you do, never make it ad-hoc as this is a sureshot way to lose control of your project.
b. The mode: that is via email or face-to-face conversation or in a common meeting
c. The format: That is how the report will look like.

The questions “How are things going?” and “How are we doing?” are crucial to managing the progress of a project. The golden rule here is to "Ask early and ask often".

The questions you need to ask while collecting work status are:
1. Tasks completed / delayed
2. Actual start and finish dates - as compared to the Project schedule
3. Milestones completed or missed
4. Any dependencies (waiting for someone or something to start or complete work)
5. Any risks foreseen
6. Any issues

However, it is not quite as simple as that - as you will potentially run into some pitfalls and problems. The most common pitfalls are:

1. The famous 90-90 rule: When stated humorously, it goes like this: "The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." Some developers will not be able to properly estimate and will almost always report tasks as being 90% complete. This is also called as the "90% syndrome".

2. Don't shoot the messenger: When a team member gives you bad news, never ever criticize or punish the one who shared the bad news. If you do that - your team will stop giving you actionable reports. You will then find out the bad news too late and when no repairs can be done. You will have to be proactive when you receive bad news.

3. Don't stop collecting project status when project goes through stressful times. The project information you collect can often reveal alternate solutions to problems on hand.

4. Use the status information that you collect. Report back to the entire team on the completed information that you have received. If it looks like you are not using the information provided by your team - you will stop receiving meaningful status soon.

Conclusion:
Frequently collecting project information from your team, then acting on it and making a collective report is the fundamental step to controlling and executing a project successfully. You will first need to establish the frequency, mode and format of how you will collect project status from your team members and then adhere to it through thick and thin times on your project.

Exactly like how you will collect individual work progress status from your team members, you will then report the status to various other stakeholders of the project. This will include the Customers, your boss and your own team.

You will find a template for this weekly report in the downloads section of the course. Please feel free to download, customize and use it for your own projects.

Reporting progress is very important because firstly the customer who is paying for the project will like to see that there is constant progress on the project and the same goes for your boss. Your own team on the other hand would like to see the bigger picture as each one of them are deeply involved in their own work and it will benefit them to see the project as a whole making progress.

This is also a great opportunity for you to put focus on the challenges you are facing and ask for assistance where required.

You should have set up a weekly meeting invitation in some sort of calendar application - perhaps Microsoft Outlook if your organization uses it - and invited all relevant people to the meeting. Additionally, for every meeting, you might choose to add optional invitees if they are required in that particular meeting.

In this lesson, we will see a basic format for a Project Status report that you can send out on a weekly basis.

Agenda item 1: Details of the Project.
Remember that the primary viewers for this report are high level folks - who will want a quick and easy to understand status of the project. There are 2 great ways to do this. Firstly, if you are using a tool such as Microsoft's Project - then it will give you a "Percentage Completed" ready-made high level report that you can use. You should religiously update your project schedule to be able to get an accurate value for this.

Alternately, you can use a Green / Yellow / Red traffic light indicators for the project status. Either ways, you will want a 2-3 line executive summary type on this item of the report.

Agenda item 2: Work done last week.
Here you may list the specific modules that are being worked on, the current phase of the project and any milestones passed. This agenda item delves a little more into details than the previous agenda item. This is intended to the technical folks on both sides of the table.

Make sure that this is again not more than 1 slide on your report.

Agenda item 3: Plan for current week.
This is an important slide and you should provide a high level view of the work that is planned to be accomplished in the current week. Another great thing to add to this slide is a high level view of the work coming up for next 4 weeks.

This is a fantastic way to give a heads-up to everyone concerned if there are dependencies on them in the upcoming weeks. Let me give an example. Suppose that the customer has to conduct User Acceptance Testing 3 weeks ahead. They will then need the time to setup their servers, and prepare a team to do the testing. And you the project manager can give them an early warning that they have prepare for this event in this slide.

Agenda item 4:Risks and Issues
This is one of the most important things you will add on the slide. There are 2 very important things to keep in mind when you include risks and issues to your agenda, on this report. Firstly make sure they are customer oriented risks and issues only. Do NOT share company internal risks - those you will have to resolve with your boss first.

Secondly, add contingency and mitigation options for every risk. We will understand this in greater depth in another lesson. Even if you don't know how to provide contingency or mitigation for a particular risk - make sure you have blank columns - and invite opinions from the higher ups. You will almost always be provided possible solutions as a result of doing so.

The objective of this meeting is not only to provide a rosy picture of great work being done in the project. In fact it will be the reverse. Because you have been doing a great job in the initiating and planning parts of the project, the customer will already expect you to have a rosy picture and that will be a given.

In this slide, as much as possible you must try to provide transparency and get as much help for yourself by constantly monitoring the horizon for risks that might become big issues.

And all the stakeholders will appreciate you very much for showing this diligence in your reports.

Conclusion
The key to great reporting is consistency. Don't let the reporting part slip - and it is very easy to do so when things are running smoothly. If you let it slip - and then are forced to report to the customers and your boss - the very first question will be - "Why did you not bring this up earlier?". You will never want to be in that position - so make weekly reporting a mandatory part of your schedule.

This lesson will focus on the different levels of testing to be done on the software for your project to achieve the level of quality expected by your customers.

This lesson is intended as a refresher - and we will not look in-depth into software testing theory. Your Quality or Testing Lead should be able to plan at a high granularity for your project. I would also love to hear about your experiences and any challenges you are facing on this topic and so please leave any questions in the comments section and I promise to respond as quickly as I can.

Let us look at the different LEVELS of Testing - starting from the lowest level and moving up. What a level means is: where in the software development cycle the testing is performed - or equally - how specific the tests are.

Level 1: Unit Testing - This is done by developers themselves on their own code - to ensure every unit of code works exactly as intended. This is the first and lowest level. Doing this properly ensures that a LOT of errors and bugs are stopped at the very source - and can greatly improve the issue resolution times of the project.

One way of ensuring good unit testing is to have monthly peer reviews. Where developers can informally review each others unit tests.

Level 2: Integration Testing. Typically, developers work on their own assigned components and when these are integrated to bigger and bigger parts in a bottoms-up fashion, errors and bugs start to show. This is because the individual components don't play well with each other as expected. These types of bugs are detected during Integration testing.

Waiting for the end of the project to integrate all pieces together is 100% SURE recipe for disaster. This is also called the "big bang approach" - when you will try to fit everything together at the end.

An alternate way is to use a technique called as "Continuous Integration". In this method, you will use a tool to integrate your project every day or every hour right from day 1 of your development phase. This is a fantastic practice - and you should get your development lead to implement this for your team.

Level 3: System Testing. This is done at the end of the development phase and tests a fully functional and integrated system. Not only should the application perform as expected but it should also behave as expected in its environment.

A best practice is to have a test plan in place and also have all test cases reviewed by an independent review team.

In this lesson, we have only seen the levels of testing you should manage on your project. We have not touched upon the types of testing such as installation testing, sanity testing, regression testing and the supremely important User Acceptance Testing of the project. We will see those in a different lesson.

What are risks?
Risks are an inherent part of every aspect in life. And we all are familiar with the concept of risks.

Risks can come from different ways for example, accidents, natural causes and disasters, some sports are far more riskier than others. Some countries have much higher risk of natural disasters such as earthquake or volcanoes or hurricanes.

Similarly financial markets are famously uncertain and therefore riskier, relying on some vendors is more riskier than others especially if they are financially unsound.

In this way, even the projects we handle as Project Managers are exposed to risks.

Here you can see a definition for risk - as an even that may or may not happen.

One very common question asked by Project Managers is "What is the difference between Risks and Issues?" A risk is something that could probably impact your project in the future. An issue is something that is impacting your project now.

Notice that I used the word probably for mentioning risks - every risk has a probability. When the risk materializes it is an issue on your project (i.e. probability becomes 100%).

Risk and issue management require planning. A risk generally has a mitigation strategy and contingency plan.

[What is Risk Management]
So, let us look at what Risk Management does.

The goal is to identify risks before they become expensive issues. Identify and plan for risks when they are cheap and easy to resolve.

Once you have identified risks that may occur - then try to reduce the probability of it occurring. Further, try to reduce the impact of damage that will happen if the risk occurs.

These three things together will constitute your risk management plan.

In this slide you will see the most common and most important risks for technology related projects. Your customer or your own company might run out of funding. Your estimates for development might be completely off-kilter. And similarly the other items that has been listed.

In all cases, you must brainstorm on risks. The key to doing this well is to get several people who have done similar projects or are familiar with other aspects of the project (for example PMs who have worked with the same client, or same technology) and get everyone's thoughts and experiences to draw up a risk list.

By doing this exercise, you will build a laundry list of risks.

The next step is to study the damage that each risk can cause to your project. In every case, you must try to fix a number to the risk. For example, you must be able to say "A new resource will cost $1000 extra to the budget".

Also, you must eliminate risks which don't make much sense. For example an earthquake is a very serious risk. However, if it should occur your priority should not be to a web application but rather to life and security of the humans. So, you must eliminate risks such as these.

You should then quantify the probability of each risk. If probability of some risk occurring is guaranteed then it is already an issue! If probability of a risk occurring is Zero, then eliminate it. In all other cases, give values of High, Medium or Low.

How serious is each risk? Again quantify them as High, Medium and Low in impact value.

Now, at this stage you will have a complete Risk Matrix - that is a list of risk items, that have been quantified by probability and impact.

At this stage comes your skills as a good Project Manager - as we will now develop mitigation plan. You should create mitigation plan for every risk.

For example, if heart attack is a high probability risk - then mitigation is to see that it never occurs in the first place. Your mitigation plan will be to have healthy exercise and healthy food and reduce heart disease causing habits. We will revisit this example again shortly.

In the last step you will develop Contingency plans for all the HIgh and Medium classified risks. A contingency plan is how to reduce the impact or damage that a risk will cause when it actually materializes. Ideally you never want to get to this stage.

That is why a good project manager will always try to identify risks early and divert them by having great mitigation plans. If this can not be avoided you will still have a backup plan - that is the Contingency. In our example from earlier, for the risk of heart attack, you will get a comprehensive health insurance plan - so that good hospitalization is possible and financial impact is reduced.

So in this lesson we have seen all the steps required to create a complete risk management plan for your project. In this exercise, common sense and experience will play a great part. So, one of the best things you can do for this is to brainstorm with peers and more experienced people while building the plan.

After the deliverables have been passed on to the customer, many projects just tend to steam out. The people on the project get pulled out for other new projects and other resources get new allocations. And all in all there are a lot of open threads - and all the knowledge will reside in people's heads. And over time, this will all be lost to you and the organization both.

But this is not the correct way to end projects.

The good project manager will ensure that this is not the way the project ends. There are a set of tasks to be performed - to properly put closure on a project.

The first task is to get the customer to formally accept the deliverables. This is done with the "User Acceptance Testing".

After the external Acceptance, you will perform an internal Review. You will sit with your team and review what went good, what was not so good and what could have been done better.

After your internal team review - you will create a formal Project Sunset review. This is a short document with quantitative data - all the project numbers projected vs. actuals. This document should go into your company's archival system.

The very last part of your project is to handover and transition. After this is completed, no more resources should be held formally by the project.

In the next few lessons we will see each of these steps in more detail.

Completing Acceptance Testing is the Holy Grail of software projects and most serious projects should not be considered be completed if this is not done in some format.

But what does this mean? At the very beginning of the project - in the Requirements Document you should quantify the deliverables of the project. And you should also enumerate a simple "Success Criteria" for your project.

And at the end of the project - when you handover the deliverables - you should invite the customer to an acceptance meeting - and test for these success parameters - and to formally sign off on your project passing these success parameters.

In simplified terms this is what the acceptance testing is all about.

There are 4 tips I will share now that should greatly help you in ensuring successful Acceptance.

Tip 1: is to put a spotlight on UAT right from day 1 both for your team and for the customer. Add UAT into your Requirements Document, put this into your schedule, help your customer set up an UAT environment if necessary to mimic production environment.

Tip 2: You grab the initiative for UAT success by offering to create the UAT test cases for your customer. This is not usually a required deliverable - but can potentially both delight your customer and also you can freeze on the UAT test cases. By doing so, you will be removing nasty surprises for both yourself and the customer.

Tip 3: If you have agreed to create the UAT test cases for your customer - then they will be a subset of your Functional Test cases demonstrating all the major workflows of your project. You should agree upfront with the customer on what these will be.

Final Tip 4: Do not word your success criteria as "Zero Bugs". For anything but the smallest of projects this is not realistically achievable. There will always be tiny minor bugs or enhancements on the system - and these will usually get passed over to the maintenance teams. You have to instead word it like "No showstopper or major bugs" - or something similar. Many of these minor bugs will not even be your team's doing but issues like compatibility problems with various outdated browsers or platform issues that might manifest in your applications.

So, use these tips judiciously and ensure success on your Acceptance tests.

About 1 to 2 weeks after the UAT is an ideal time to do a team review - you should allow a this little time to pass to gain a little more hindsight into the project.
--
The best way to arrange this review meeting is to schedule maybe 2-3 hours, get all the hands involved from all disciplines in an informal setting. As a project manager, you will have to ensure the meeting is carried in the right spirit and degenerate into a finger pointing session.
--
Ideally, there are 3 things that you will want to review with the team. First the positive things achieved from the project. Then the improvement areas and then the negatives.

The most common positives will be things like re-usable design and code, research documents and such like. Your goal will be to ensure these positives are properly packaged and made available to yourself and the rest of the organization for future projects.

Every project will also have improvement areas. This is where the hindsight part comes in. With the knowledge that you have now gained from doing this project, what could perhaps have been done better the first time around? It is a great exercise to discuss this honestly with the team and also to document it.

The last part of the meeting is to discuss the negatives learnt. What mistakes were done and learnt? For example, what risks were not recognized? Did estimates on time and effort turn out reasonable or not? Were there design issues - and so on.
--
The key bottom line of this meeting is to make sure all the learnings are fed back into future projects. These learnings will provide powerful inputs to all future project artefacts - right from the WBS and estimates, High level design, implementation and risk analysis and so forth.

There is one more way that this meeting contributes. As a Project Manager you will be required to provide performance reviews for all the team members - either formally or informally for your own records.

You should create these performance opinions only after the team review - to ensure you keep the full project perspective in mind while creating them - instead of being coloured only by the final stages of the project.

Software schedules are hard to create and even harder to review. There are just too many unknowns involved.

So, how do you review a schedule when it is created by your team?

Here below are a set of questions that will force you and your team to look into the schedule even more deeply – to shine light into the nooks and crannies – and force out the assumptions, superstitions and assorted crawlies to come out of the woodwork.