Posts related to management methods and related content

Earned Value Management – Formulas, Calculations & Examples

Any project needs a constant monitoring of time, material and cost usage. If you see your team falling behind on schedule, you can add more resources to stay on track. But that could result in increase of project cost (Unless you are not paid overtime!). This concept is commonly known as triple constraint in the Project Management world and it means that if either one or more constraints (time, cost or schedule) change in positive or negative direction, the other constraints will be affected as well.

To stay on track we universally use the tried and tested Earned Value management calculations. Not only are they used for monitoring and control of a project; they are a valuable set of tools for reporting performance to the stakeholder or sponsors or your program manager.

Here is an example of a Project Performance Report.

Performance Report sample

Changes in project baselines can occur due to either internal reasons or external factors; for example internal reason could be resource turnover and external reason could be change in requirement by business)

Lets assume there is a change in requirement and we invoke change management to have those changes approved and added to the project baselines. That will cause an increase in budget & time and they would need to be recalculated. Now we might also need to forecast “If” situations such as what if the schedule is immovable then how many more resources would I need to add and what would be the additional cost incurred?

These questions and analysis can be easily done via EV calculations.

Here are the terms and formulas that are most commonly used. I created this diagram depicting the terms in pictorial form for easier understanding.

Earned value management Diagram

  • Planned Value (PV): This is the estimated value of work that is planned to be done.
  • Earned Value (EV): EV is where you are currently in the project. i.e, earned value of work completed.
  • Actual Cost (AC): This is the actual cost of the work completed.
  • Budget at Completion (BAC): This is the project’s total budget that is determined by the P.O.
  • Estimate at Completion (EAC): This is a forecasting term that will help in determining expected total cost in the end. EAC = AC + (BAC – EV)
  • Estimate to Complete (ETC): This is expected remaining cost. (from now until the end) ETC = EAC-AC
  • Cost Variance (CV): EV-AC. You want your earned value higher than the actual cost.
  • Schedule Variance (SV): You again want to keep your SV positive.
  • SV=EV-PV
  • Variance at Completion (VAC): This is the variance calculation to determine whether the project is running over or under budget.

Here is an example , let’s say we hired a coder with billing rate of $50/hour to code 500 lines of code in 5 days (total of 40 hours). The coder is expected to code 100 lines/day and work 8 hours/day.

Scenario on Day 1:  Coder worked 6 hours and finished 200 lines of code

  1. PV = $400    (per 100 lines of code or 8 hours of work at $50/hour)
  2. EV = 200 lines of code x $4/line of code = $800
  3. AC = 6 hours x $50/hour = $300
  4. CV = EV – AC = $800 – $300 = $500
  5. SV = EV – PV = $800 – $400 = $400
  6. CPI = EV/AC = $800/$300 = 2.67
  7. SPI = EV/PV = $800/$400 = 2
  8. BAC = Total Project Budget = $400/day x 5 days = $2000
  9. EAC = AC + (BAC – EV) = $300 + ($2000 – $800) = $1500     — Atypical, that is, variable work each day by ignoring the past. To be used when all future work will be accomplished at the budgeted rate. –
  10. EAC = BAC / CPI = $2000 / 2.67 = $750  — Typical, that is, assuming same amount of work per day and same spending per day will continue. –
  11. EAC = AC + [(BAC – EV) / (CPI x SPI)] = $300 + [($2000-$800)/(2.67 x 2)] =  $525   -Used when dealing with poor cost performance and the completion date is firm.
  12. ETC = EAC – AC = $1200
  13. VAC = BAC – EAC = $500
  14. TCPI = (BAC – EV) / (BAC – AC) = 70.59%

Perform same calculations for the following daily scenarios:

Scenario on Day 2:  Coder worked 8 hours and finished 50 lines of code

Scenario on Day 3:  Coder worked 6 hours and finished 100 lines of code

Scenario on Day 4:  Coder worked 10 hours and finished 50 lines of code

Scenario on Day 5:  Coder worked 10 hours and finished 100 lines of code

Earned Value Management Formulas and Calculations example


EVM Formula graph

I created this spreadsheet that will perform all the calculations for you and also give you budget status on daily basis(See “Over or Under Budget?” column). Just input the cells highlighted in Yellow.

And here is the attachment for the Excel sheet –> Excel Spreadsheet for EVM Formulas and Calculations

Determining the Critical Path and Float

In spite of Critical Path being such an important method of managing a successful and timely delivery of project deliverables and as the name implies it being “critical”, it is surprisingly overlooked. How many times have you experienced a setback or delay in completing some of the project tasks whether due to any unexpected issues or dependencies or identified risks and things of that nature? To stay on track, critical path helps you mitigate the risk of falling behind the set & agreed schedule and also assists in managing those delays in a way that will cause no real negative effect on the firm project completion date.

Critical path method is used to calculate early & late start dates and finish dates without taking into consideration any resource constraints. Critical path method highlights that one path, out of various different paths in your schedule network diagram, that results in latest completion date of the project. Some of the tasks with a calculated float greater than “0” can be delayed but the tasks that fall under the critical path cannot be delayed. Any delay will cause increase in resources, schedule and related cost. Microsoft Project has an option for automatically displaying the critical path that should be monitored closely by any project manager. The rationale being that there could be delays on certain tasks but the maximum delay (without affection timeline) could only be what is permissible by the calculated slack or float. So when you notice your team is going slow on certain tasks and missing the completion date, you will need to figure out a way to restructure the dates for those delayed tasks in such a way that the project completion date is not affected. This is where critical path and slacks comes into picture.

We can easily find the critical path using Microsoft Project and also visually highlight the entire path in Gantt chart. Here are the sample tasks I created in MS Project; You can see the tasks highlighted in yellow(in task list) and red (in Gantt chart) are the tasks on critical path.

Critical Path in Microsoft Project with slack


Now let’s assume Task 2 has been delayed to start on 5/29 instead of starting on 5/21 as originally planned. Since Task 2 has a slack of 9 days, we can delay the start date upto maximum 9 days before affecting the project completion date. See below on Gantt Chart how moving task 2 has no negative effect on the total time frame.

Critical Path Non Critical Tasks moved


Calculating the slack manually will clear this concept from the ground level. Let’s say you have 9 WBS tasks in your project plan and the durations have been determined for each task. Next step is to determine the predecessors for each subsequent task. This forms a network schedule diagram which will be used for calculating the Critical Path.  Start by designating the acronyms ES, EF, LS and LF to the 4 corners of the task box as shown in the diagram below.

Critical Path and Float1

Next step is to perform Forward Pass calculation to determine earliest start and earliest finish of each task. You start by assigning the value 0 to your first ES on Task 1.  You will then add the duration for task 1 to the ES value (which is Zero for first task) and determine the EF. So EF for task 1 is 0 +2 = 2.

You will carry the values of EF =2 to ES of task 2 and ES of Task 3 since both the the successor tasks. Again you will add ES + Duration on Tasks 2 and 3 to get EF values.

Now before you proceed, notice that Task 4 has two predecessor tasks. So you will need to calculate the ES for both of the predecessor tasks (Task 2 and 6) and pick the highest EF value.

After calculating the Earliest Finish for Task 2 and Task 6, we will pick 16 as ES for Task 4 since that is the highest number out of 7 and 16.

Keep repeating these steps for each task until all ES and EF are calculated and determined.

Critical Path and Float2

Backward Pass needs to be performed for calculating the LF and LS and is followed in the opposite direction of forward pass, i.e, from Task 9 to Task 1.

Start by taking the Earliest Finish value of the last task and assign it to the Latest Finish of that new task. Now subtract duration from the Latest Finish to get Latest Start.

The LF of Task 9 is 37, so the Latest Start will be 37 – duration 3 = 34.  Designate LS value to the LF of preceding task (from right to left perspective).

Keep performing the same steps until you reach Task 3. As you can see the values for LF of Task 3 can be carried over by both Task 5 and Task 6. Unlike forward pass method where you pick the highest values you will instead pick the lowest of the number. So the correct value carried over to LF of Task 3 will 10 (from 10 and 18 of Tasks 6 and 4 respectively)

Critical Path and Float3

The final step before we can determine the tasks falling on the critical pass is to calculate the float or slack. Float is the number of days a particular task can be delayed until the project completion is affected negatively.

To calculate float you will need to subtract Earliest Finish from Latest Finish (LF-EF) for each tasks. After calculating the float for all the tasks, you will note that there is a path where all the tasks have Zero float. That means there is no slack or delay allowed on any of those tasks. In our example, the critical path is in the order of Task 1, 3,5, 4,7 and 9.

Critical Path and Float4

Critical Path Report

Here is the video depicting each steps.

A case for using a shared information library

Over time, an information library can be a great source of information for your team. Whether your company uses Sharepoint or Microsoft TFS, FileStack or OneHUB the idea is to adopt and implement a process & a system for archiving and maintaining code changes for each client as well as any break-fixes or subsequent enhancements using SharePoint site.

The Objective

  • Help track changes for each implementation.
  • Check in the code changes per bank and maintain a history of all code revisions.
  • Use of a break-fixes SharePoint page that will contain all the changes made by anyone archived by date.
  • Have a separate section or page that includes all the comments or important information about an implementation.
  • Shared internally across various gourps such as Product Development Group and Product Support Group.

The Opportunity

  • There are many “break-fixes” or modifications that are added to an existing code base over a period of time. Tracking those changes as well as handling the job failures in absence of the primary developer can be challenging and a backup resource will face numerous challenges without the 360 degree knowledge of a particular implementation.
  • Will serve as a search site for any keywords to quickly check if there is any information around it. For example, a keyword search of “Custom code to rollup particular loan types” will yield a result of any items that were checked in or added on the SharePoint site. The scope of the search could include all the banks and will return results related to the keyword.
  • Repository of stored information may include added code snippets, additional logic or requirements implemented in the past, known bugs, discussions and log of any relevant information.
  • Will minimize the amount of time needed for a new or a backup resource to jump into job failures or other issues. Such site will also serve as a knowledge base and as a reference point to check before diving deep into any task.
  • Global search on SharePoint will enable your to look for a particular piece of information across all the banks. Such a wealth of knowledge will increase clarity and negate the reason to reinvent a similar work product that might already be in use at some other bank.
  • Important communications as well as details and insight on all clients can be maintained and retrieved when needed.
  • Such a site will help capture more accurate and detailed information along with the business rules and logic.


  • Create a SharePoint site that will have following features –
    • Code Versioning and comments on all subsequent check-ins of the original code.
    • Archival of all the changes along with discussion board and comments section.
  •  Site for maintaining other key or supplemental information, which can be beneficial to all, as a common knowledge.
    • Create a site for archiving a set of common code that can be reused at a different implementation.
  • Site for archival of “know-how” and “How to” knowledge or tips.

Other Benefits

  • Reduced work time for any fixes or “job fail” resolutions.
  • Easy transition of knowledge between responsible resource and new or a backup resource.
  • Negating the need to re-invent the wheel by making use of existing code library.



With a growing list of  clients, incorporating a shared repository system will surely help meet the challenges of maintaining relevant and critical information for each implementation.

Understanding the Requirements Traceability Matrix

One of the important documents that stand out during project planning is the requirements traceability matrix (RTM). It is the heart of requirements collection phase and is a very effective document for maintaining, tracing and implementing the requirements as the project progresses.

While working in an SDLC project, there tend to be numerous resources involved for different phases. We can’t expect all of them to speak a common language in terms of referring to an item or a task or even the process itself due to different background on their skill set and type of job roles.

One term I often see people getting confused is the requirements traceability matrix and Mapping matrix. The key distinction is that the former is furnished by the Analyst throughout the requirements collection phase and the latter is produced during the BRD or mapping of physical requirements to their technical components (example – an item tracked through different schemas and databases and associated business rules).

The requirements captured and finalized in the requirements traceability matrix will help shape the WBS tasks and Activities list, which in turn will be used for developing, project schedule. That was a very high level description of the process but when you put all that into action there are many steps and many documentations resulting in the end.  That’s a topic of discussion for another day!

Going back to the Requirements Traceability Matrix, the project team manager and the analyst will work closely with the SMEs and stakeholders to capture their vision and goals of the project objectives more accurately and also capture supplemental information like who requested the requirement, business justification, affected components, business rules, related WBS entry, source etc. that comes in handy during the entire project. We’ll see some of the elements used in the matrix more closely in the attached sample.

So how are these different elements captured and what are the steps involved?

The requirements collection process starts with the project manager meeting with the SMEs and Stakeholders by setting up one or more of the following activities.

  • Interviews
  • Focus groups
  • Cross-functional team meetings
  • Brainstorming sessions
  • Facilitated workshops
  • Prototype (my favorite and most common)
  • Surveys and Questionnaire

In my experience, acquiring the prototype and following it up with additional questions around the components requested is one of the most effective ways of gathering requirements. Without examples or prototypes, the analyst will be left scrambling to understand the business requirements and translate them into technical deliverables. This is because at times the business users/stakeholders tend to be vague in what they want in terms of intrinsic needs while defining a deliverable. I shouldn’t say this but many of the users/stakeholders are of wavering mind and will change their requirements as the project timeline advances. Which in my opinion is fine because during project progression the corporate goals and direction of the organization might change with their changing consumer market and those changes in goals would need to be aligned and incorporated in an on-going project. This is where RTM comes in handy and is the master sheet for “tracing” the requirements and the details around each of them. One thing to remember is that there should be unique identifier for each requirement and they should never be deleted or re-ordered.  This is so each of the requirements that are referenced throughout the communications and also included in the BRDs or other documents like RAID would mess up the association and cause confusion. I always use a flag on all the entries that states if the requirement is current or outdated & whether it is needed or not.


Here is an example of a Requirements Traceability Matrix document.

Requirements Traceability matrix example

R.A.I.D Document

In my earlier post “8 Must-Have Documents in a Project Manager’s Briefcase” I mentioned R.A.I.D document. Today I will dive a little deeper and show you some examples. R.A.I.D stands for Risk, Assumptions, Issues and Decisions. You might see different variations of this document; some people like to use “Dependencies” instead of “Decisions” whereas others use “Action” in place of “Assumption”. Personally I feel that the dependencies are anyways captured as a part of issues and action items are also listed for mitigation of  risk and issues log. So it would make more sense to use the categories – Risk, Assumptions, Issues and Decisions.

This is what I wrote in my earlier post and I am just pasting it back instead of reinventing the wheel!

R.A.I.D Document- This document will have sections for documenting and maintaining risks, assumptions, issues and decisions logged throughout the project lifecycle.

  • Risk Log – This document would contain the detail about the risk, affected components, impact on timeline, level of severity, team member(s) responsible for resolving the risk, action needed, cause of the risk, impacted group, impacted work packages, resolution target date etc. All risks should be numbered uniquely and in the order of discovery and should be referred by that number throughout the project life cycle.

RAID Document -

  • Assumptions- This section will list out all the assumptions before the commencement of project and during project execution as you follow through your activities. Every project will have assumption such as availability of required data, estimated disk space for database, availability of required software and things of that nature.

RAID Document -

  • Issue log – This section is similar to risk log and would contain list of all the issues numbered uniquely and in order they were received along with the impact of the issue, priority,  affected components, team member(s) responsible for resolving the issue, status indicator, actual reported date, projected completion date, dependencies etc. Entries in the issue log should never be deleted or moved once they are resolved or there is change in status or priority and should have unique id so they can be refereed throughout the project by that id.

RAID Document -

  • Decisions- This section documents the decisions taken by any individual authorized in their position to do so, decision details, department/group, date recorded, impacted and affected components.

RAID Document -

Hope this is helpful to anyone trying to build a template. Or just contact me if you need my excel sheet.

Consequences of Over-Promising or Over-Delivering and the Right Process

At the end of the project if you deliver less than what was expected then you are pretty much on the path of risking your reputation. If you deliver more than the expected you are a hero. Many a times, especially with new managers taking new responsibilities and authority, more features are delivered by intention than what was asked for originally in spite of falling behind budget and added constraint on resources. It stretches and burns out the project team by making them work overtime and causing a higher stress level, all because of the manager’s commitment and desire on providing extra features that was never asked or intended in the first place.

This is a detrimental approach due to the fact that there could be business reasons why certain features are shut out on purpose or maybe the features are being held back for next release, maybe their systems are already maxed out on resource usage and cannot accommodate any extra functionality which hasn’t been scoped for. This is commonly known as “gold plating” in project management world and advises to clearly stay out of this practice.

The habit of delivering extra value or features also skews the project baselines for any future projects since the client/business users will perceive receiving extra features as an expected act in spite of being not accounted in the project scope or budget.  Gold platting eventually also leads to feature request by the customer in an ongoing project along with more changes over time. The nature of most businesses is that they change; the direction and strategic goals of an organization or a company changes quarterly or on yearly basis thereby potentially affecting any current & on-going implementations. Any added features or changes requested without invoking change management most certainly leads to a point of failure.  This is due to the fact that added features means more resource effort hours which translates into higher than assessed budget.

An example of correct procedure to follow during any change request is to assess the impact of this change, get authorization and approvals from appropriate authorities, change the scope, time and cost baselines to accommodate the changes, invoke change management and get approvals, change the project schedule and timelines, send clear communications on new dates and milestones and implement the changes.

Now there are times when a development team is working closely with the business user/base and they form a certain level of relationship where the developers are obliged to incorporate constant changes as requested by the client. Managers should be firm in controlling the scope and making sure proper procedures are followed and right parties/team members are involved in an open discussion while making clear its added impact on the ongoing work.

The practice of delivering extra without invoking proper protocols and process will cause more damage to your reputation and impact team morale due to over utilization. So the next time you think of a brilliant idea that will, in your eyes, add value to the business/project, go ahead with discussions by involving stake holders, program managers or client or committee who are in position and authorized to approve any changes and let the proper process take care of the rest!

8 Must-Have Documents in a Project Manager’s Briefcase

Ok so it’s not the 1980’s and we don’t carry briefcases (unless you work at Wall Street!!) but let’s say there is a shared location on the network where Project Managers can archive and share certain documents with the intended members. What are the documents you are most likely to seed? I compiled a list of essential documents that I deemed necessary to be maintained in an accessible centralized network location by Project Managers as an aid to their project management activities.

  1. Stakeholders Register – This document should contain details of all individuals who are impacted or affected by the project in any capacity and have a stake in the project. It should also state their roles, department, contact information, committee etc.  Certain information such as level of interest, involvement, influence and communication expectations should be shielded from members other than project manager since this information is only for aiding the PM in performing his job efficiently.
  2. List of all team members – This document would state all the members of the project team working on the delivery side. Level of involvement, work packages /tasks assigned, responsibilities, authority and hierarchy should also be included.
  3. Meeting minutes – After conclusion of each meeting there is either a conclusion or a pending state of matters that would need to be documented. The document would basically include the meeting details as well as highlights, outcomes, decisions, concerns, change request, risks etc. that were discussed. It helps stay on track for all the activities that would follow and keeps the attendees on the same page and in agreement. In the event of back tracking by any member it is helpful & easier to go back to the meeting minutes and highlight the notes and action items that were approved.
  4. R.A.I.D Document- This document will have sections for documenting and maintaining risks, assumptions, issues and decisions logged throughout the project lifecycle.
    • Risk Log – This document would contain the detail about the risk, affected components, impact on timeline, level of severity, team member(s) responsible for resolving the risk, action needed, cause of the risk, impacted group, impacted work packages, resolution target date etc. All risks should be numbered uniquely and in the order of discovery and should be referred by that number throughout the project life cycle.
    • Assumptions- This section will list out all the assumptions before the commencement of project and during project execution as you follow through your activities. Every project will have assumption such as availability of required data, estimated disk space for database, availability of required software and things of that nature.
    • Issue log – This section is similar to risk log and would contain list of all the issues numbered uniquely and in order they were received along with the impact of the issue, priority,  affected components, team member(s) responsible for resolving the issue, status indicator, actual reported date, projected completion date, dependencies etc. Entries in the issue log should never be deleted or moved once they are resolved or there is change in status or priority and should have unique id so they can be refereed throughout the project by that id.
    • Decisions- This section documents the decisions taken by any individual authorized in their position to do so, decision details, department/group, date recorded, impacted and affected components.
  5. Detailed Project Schedule – This can be in the form of Gantt chart along with the timelines mapped across various activities. One of the most widely used application is Microsoft Project where in you can list the WBS entries, task name, duration (calculated from the dates), start date, end date, resource name etc. When the cost per effort hour is factored in and added, it helps a Project Manager with budgeting and managing the project P.O.
  6. Team Calendars – This is your team’s calendar where resources will mark their planned vacation, section meetings, training, jury duty, conferences, family/medical leave, flex hours and all corporate holidays. This will help avoid project managers being caught off-guard and especially when your project is on tight schedule and is transitioning into critical activities. It would be detrimental to project delivery if the resources required are not available at right time.
  7. Budget Status Reports – This document would state the breakdown of effort hours booked by your resources, high level project effort hours, translated budget in dollar amount, remaining budget, and burn rate. Budget can also be tracked along with the WBS entries on project schedule document.
  8. Weekly Status Dashboard/report – This deck would contain project status reports like important updates, status color (for ex-green= on track, red= delayed with issues, black=on hold) , work accomplished in previous week, planned activities, important upcoming meetings, milestones, project stage etc. This document can be high level and customized to the need just like any of the above documents.

Spotting a Quality IT Resource

What makes a developer great or stand out among others? Should the focus be solely on their technical skills? To what extent should their other non-technical skills and qualities be factored in?

Project managers know that the success of their projects depend on having excellent developers in their team.  Hiring top notch developers is directly proportional to the success of any project. The next steps revolve around recognizing the right talent and whether the potential candidate would be a good fit in your team.

Conducting interviews involving cross functional team members and assessing the developer’s response to the interview questions is a good start. Theoretical test and mock scenarios helps in gauging their skill sets and interactive practice test could be implemented to validate their technical skills and also of their understanding of the subject in a less technical language. Analyzing their response would help indicate whether their approach and style of work would fit in your culture.

Other pivotal qualities and traits would be assessment of their attitude and desire to perform at a constant high level and delivering the results as per or beyond expectations. The willingness to help and assist while also being able to work independently on per need basis is vital as any work package could either require working within a team or as a sole contributor.

Understanding and being able to seamlessly fit into the desired role and being comfortable & confident with the responsibilities should be a judging factor.

A developer’s sense of desire to grow and contribute with a proactive approach should also be taken into consideration as it allows them to bring new and creative ideas as well as contribute towards potentially bringing in a new line of business. Developers tend to have the highest visibility when it comes to core development work like designing, coding, building components etc. and the developer’s desire to contribute proactively by seeking continuous improvement opens up the door to opportunities for making systems/code better or even propose new initiatives that could make project or project goals better than the planned original.

I have seen numerous times during ongoing project work that an expert developer fueled with a sense of desire in contributing and improving will propose or recommend a different approach, process or design when implemented brings a better value for that particular work product or the end product as a whole.

I am sure there are other vital qualities in an exceptional developer depending on the situation and from a different vantage point of need and desired qualifications. Feel free to leave your thoughts in the comment section below and I will incorporate them into this post if valid.

Project Management Essentials – Gathering Requirements for a Project

As a project progresses through the planning phase and once the scope has been defined and documented the requirement gathering phase takes over.  It is a process of defining and documenting stakeholders need for meeting the project goals and final outcome. Requirements gathering not only consist of collecting the specifics of what an end product should look like but also pertain to gathering other vital supplemental information surrounding the end product. This supplemental information guides us and gives a deeper view of any particular requirements. The requirements documentation will contain goals and objectives that go in the requirements traceability matrix, level of service, performance requirements, security, quality requirements and acceptance criteria as well as support and training requirements.

A charter is a good place to start along with the list of stakeholders as it helps figure out and formalize a plan for proper involvement and coordination of requirements gathering activities. There are different ways of extracting the needs, some of which are discussed below.

Interview & Discussion- In interview session can be scheduled with the subject matter experts of stakeholder to ask questions surrounding the project objectives outlined in the charter. The responses would be documented and further follow up sessions would be scheduled on iterative basis until all the requirements are fully collected.

Focus groups and workshops – Sessions can be held with the SMEs or conduct cross functional meetings wherein members of different groups or departments would contribute on helping understand and shape the requirements.

Group decision making techniques include brain storming and voting as well as Delphi technique. Beyond these, questionnaire and surveys can be conducted and the majority of response or similar responses will be further discussed and become part of further conversations and clarifications.

Prototypes – One of the most common techniques I have encountered are creating mock ups or models. Mockups are a great way to convey what the stakeholder is looking for in a product and the final outcomes. Mockups can be a PowerPoint presentation detailing report design and displays the look and feel as well as elements needed in the report along with other business logic.

The requirements traceability matrix is a very important tool that would be used frequently by project managers to track, trace, document and maintain all the information about the requirement as well as information surrounding that requirement. Requirements traceability matrix document is basically an excel sheet with following columns.

Requirement id – Each requirement should have a unique id and this should not be mistaken with row numbers. The id can be numeric and in order but they will never change even if a new requirement is added or deleted from the middle of the list.

Requirement – This is the context containing description of the requirement.

Source – This field will state the person/group from whom the requirement originated.

Business Need – States the need for that particular requirement on why and how it will help build and shape the outcome.

Project Objectives – This describes how the requirement is aligned with the project objectives.

WBS deliverable – Each requirement is translated eventually into one or multiple Work Breakdown Structure entries. This field will state all the WBS and other work product dependencies.

Test Strategy – This field will state how the requirement will be tested for quality control and quality assurance and to ensure that acceptance criteria will be met through the strategy.

Organization – States the group or department who requested the requirement.

Status – Contains the current status of the requirement. This is frequently visited throughout the project and updated as and when a requirement undergoes status change.

Management Theories

What type of manager would you like to be know as? Someone who micro manages or someone who inspires or someone with leadership and command? Managing your team or resources can be a daunting task as the team member’s personalities differs. In my experience I found success while dealing with each resources on a case by case basis by focusing on their personalities, needs and expectations. For instance I have seen a team member completely content with their current job while another member is quite restless and is looking to progress their career on a fast track whereas the third person is partly happy with their current situation and would like to seek more opportunity within or outside of the organization.

There are several known theories managers adopt while working with their team of which few are discussed below.

  1. Expectancy Theory – The employees are often motivated by the positive outcomes and rewards related to exceptional work they did or by performing work that exceeds expectations.
  2. Hygiene Theory – This theory takes into fact how employees feel about their pay, compensation, benefits and work conditions.  Obviously these are some very important criteria that employees consider for being satisfied.
  3. Theory of Needs (McClelland) – The theory assumes that people are motivated either by power, achievement or affiliation and they should be managed accordingly to the category they fall under.
  4. Maslow’s Hierarchy – People climb up the pyramid by fulfilling the lowest level and moving up. The bottommost and the first level is “Physiological” where the basic needs like food, shelter, water are fulfilled. The next level is “Safety” where people feel safe and secure at their work. There is then “Social” level where employees like to be surrounded by people they like and are comfortable to work with. Next is “Esteem” where employees will be admired for their work by their co-workers and accepted as an important part of the team. The last one is “Self-Actualization” where people learn to live their life by their true nature and capabilities and that they will be happy to perform the tasks that they would like to and not what they dislike and is imposed upon them.
  5. Theory Z – This theory takes loyalty into consideration and suggests that job security will mean a higher satisfaction level and desire to contribute in a positive way.
  6. McGregor’s Theory X and Theory Y – Theory X suggests that managers think that all people dislike work and that they should be micromanaged to get desired output. Theory Y suggests that people are self-motivated and that they need minimal supervision and guidance to get their work done.
« Older Entries