How to determine Critical Path Tasks on Projects?


Image

The Project Management Body of Knowledge (PMBOK) defines the critical path method or more commonly termed critical path as “the sequence of schedule activities that determines the shortest duration of the project.” The critical path methodology technique can also be applied to “determine amount of float” on various logical network paths in a project schedule network” that reflects minimum total project duration.

What is a Critical Task?

Any task in a project schedule network becomes critical if:

  • It has no slack
  • It has a Must Start On or Must Finish On date constraint.
  • It has an As Late As Possible constraint in a project scheduled from a start date.
  • It has an As Soon As Possible constraint in a project scheduled from a finish date.
  • It has a finish date that is the same as or beyond its deadline date.

Note that a task stops being critical when it’s marked as completed, because it then can no longer affect the completion of successor tasks or the project finish date.

Identification and close monitoring of all critical tasks in a project is a first step to ensure they can be better managed. Fast Tracking & Crashing techniques are most commonly used by Project Managers to manage critical tasks on their projects.

Shyam Verma, PMP, ITIL
IT Project & Program Delivery Professional
LinkedIn:spverma. Twitter: Shammy11


Why You Should Delegate More


Work delegation is an art that can be a win-win for both a leader and subordinates. Still rarely you find leads and managers do it right way. There are two extremes we often see in the workplace. A control freak, who is obsessed to do everything by himself, It might be a reflection of either a job insecurity or a false obsession with perfection or doing everything his or her own way. Both these approaches are killers (literally) and does not produce effective or efficient outcome.
What to Delegate:
Delegation is a fine line where one has to decide what need to be delegated and what needs to be kept. There is a clear choice between mundane or routine tasks which are not important but have to be done. These types of tasks are easier to delegate as they can be done by a junior staff with acceptable or desired level of quality. At times this may involve some on the job training. These tasks are best targets for delegation and require little or no supervision over a period of time and can be real stress reviler.
Contrary to this, there are some highly technical or complex tasks which require higher level of expertise or domain experience. For example, presentation of project report to steering committee or Proposal for an upcoming project. Delegation of these type of tasks are not easier and can’t be delegated to someone who is either not qualified so lacking the ‘expertise’ or someone does not simply have the skills or interest to perform this on your behalf. To be able to delegate this type of tasks, one has to groom someone overtime and spend quality time coaching on. Most leaders do not think delegating these tasks because these tasks are also something that reflects their key skills or so to speak USP and delegating these tasks may actually make manager’s position replaceable!
How To Delegate:
There are simple steps to ensure the delegated task get done to desired level of success and you don’t end up spending more time supervising.
• Select the task and Find a resource with suitable skills
• Provide sufficient work instructions & measurable goals
• Focus on task “Objective” of the task not procedures
• Supervise, Review periodically & give objective Feedback
• Step in to help if needed, else do not interfere.
Expect teething problems
If even after your clear instructions and support you see that the task is back on your table for your action, the delegation clearly did not work. Many managers find themselves in this position often and don’t know what to do next. Some even accept the fact that their team is not up to the mark for the responsibility.
First, in some cases, the subordinates who have been delegated the tasks bounce the task back to the manager because they don’t want to take the risk or be blamed for the failure. Second, it may also be possible that manager and the subordinate do not have the same understanding of the tasks to be performed and the empowerment going with that. Clarify the expectations and ask for his / her next action plan. Support with your inputs but do not micro manage or step in when not required.
It is important that these challenges are discussed and worked through before abandoning the idea. This is because if delegation fails, both parties loose. Subordinate doesn’t see any room to grow and Boss feels stuck with routine and mundane work load & not finding time for critical and strategic project work.

Shyam Verma, PMP, ITIL v3
IT Project & Program Delivery Professional
This article is also available on http://www.prozenconsulting.com

Resolving project team disputes effectively


We all know how frequently a small disagreement within the team members can  flash-over into a full conflagration in no time, scorching you and your colleagues in minutes. What it means is that you as the leader of the project team need to think on your feet and take a quick decision to douse the flames before they have any significant negative effects on the team and project outcome.

Conflict resolution does have some trusted and tested techniques that can be used as per the specific situation.  These techniques are listed as below;

  • Confronting: A resolution technique that involves face to face dialog and focuses on win-win outcome
  • Compromising: This is where stakes are small and both parties looking for a quick resolution
  • Smoothing: One party loses or obliges for the sake of achieving the overall larger goal or for future trade off
  • Avoiding: Temporary solution to postpone issue for future. Leads to recurrence of the issue
  • Forcing: Win lose situation where one party wins at the expense of other party; rarely brings a lasting solution

The best answer is to have a conflict resolution mechanism set ahead of time – for example ground rules for the project team. This is something that team already has in place and agrees to abide by and has a buy in from all affected members.

The reason this is the best alternative to choose because trying to resolve a conflict when tempers are high may lead to distrust from one of the parties.  While if you have ground rules laid out well in advance, there is no way it could be ignored by any party privy to the conflict. What has to be done is ascertain the facts and view it from the perspective of the rules already in place! Team norms should ideally be established when the unit is first formed. These are rules that help the group run effective meetings and make sure everyone is heard. Some examples of team norms:

  • Meetings will begin promptly when scheduled.
  • One person talks at a time; there are no side discussions
  • De-personalize discussion of issues – no attacks on people
  • E-mail and other communications will be answered within 24 hours.
  • In event of a disagreement, a final decision would be made by the PM/GM
  • When we pose an issue or a problem, we will also try to present a solution.
  • No responsibilities will be assigned unless the person be assigned the responsibility accepts it

Do you have your ground rules set up for your project team?

Shyam VermaPMP, ITIL

IT Project & Program Delivery Professional
LinkedIn:spverma. Twitter: Shammy11
This article is also available on blog site http://pmpower.wordpress.com

Scope definition through User stories


User stories

The benefits of achieving a working software in less money, better risk mitigation mechanism (because you test early and test often) and dependence on process not individuals is one of the key reasons that XP has become one of the most preferred software development methodologies in recent years. Agile practitioners term User stories to be “Technique of expressing requirements as user stories to be an effective approach on all time constrained projects and are a great way to begin introducing a bit of agility to your projects & requirement management approach.”

If you happen to be one of those PMs who need to deliver your project in such fashion chances are you are most likely to use your scope statement e.g. project requirements in terms of user stories rather in standard functional requirement document. Hence it would be invaluable to know how you can employ user stories to define and plan project scope.

What are user stories?

A user story describes what functionality is required from the perspective of business users in simple or plain English running through different steps or stages to accomplish desired functionality. In simple terms, a user story provides the clear understanding of who wants the functionality, how it would work and why this functionality is required. In most cases user stories are written by customer or a customer representative working with a developer where developer may ask some questions to clarify the user actions but does not influence the idea creation process. User stories are used mostly in agile software development methodologies to provide the basis of features required in the software.

Development Process: While business user or customer narrates the scenario, developer makes notes on a 3×5 inch Card with functionality or requirement name, user action description, test condition, rough estimate and any other relevant point. For example, ” As a business user I want to be able to search for my customers by their first and last name,” or the “Application starts by bringing up the last document user was working with.”

The 3 basic tools used in the process are namely, Card as mentioned above, details around Conversation where details are noted as discussion with business user happens and thirdly Confirmation or Conditions that must be met for for the basis of user acceptance.

In case there is any ambiguity on the user story or it is deemed complex or too big the process of refinement is repeated until the story is concise and agreed by both user and developer. Please note the user story is not supposed to be definite business functionality and changes to the functionality are accepted at the time of development or even testing. From that perspective the process represents one of the key features of Agile development.

Advantages: User stories are a quick way of eliciting customer requirements without having to spend too much effort on formalized requirement documentation and bypassing overloaded administrative tasks for maintaining them. The purpose of user story is to respond promptly with less overhead in rapidly changing real-world requirements

Limitation: since the User stories are informal way to elicit requirement the test scenario for acceptance purposes should be in place without which the implementation of the requirement do not have customer acceptance.

Shyam Verma, PMP, ITIL
Program & portfolio Mgnt professional
LinkedIn:spverma. Twitter: Shammy1

There are three basic tools used in the process namely Card as mentioned above. Secondly details around Conversations where details are noted as discussion with business user happens and thirdly Confirmation or conditions that must be met for acceptance.

Managing Project Scope Effectively


For most projects, keeping the project schedule and cost in control pose the biggest challenge and stake holder expectation after the level of quality. A tight definition and active management of project scope can not only deliver instant results but also relive you of unnecessary squeeze on your project resources. Here are some ideas that can put you back in track or give you some directions on your next high profile project!

  • Scope statement: at times the scope of your project is not very clearly defined from the beginning or is under defined to say the least. Please remember the scope statement that was prepared at the time of Pre-Sales stages or before the actual analysis phase may not be sufficient or complete. So spend some time verifying the fact if some additional things made their way or something that was cut to meet timeline or budget constraint. It is a good practice to serialize key business requirements for estimation of time and cost. Also remember the initial scope statement is only for an interim period until the scope definition is completed as part of planning phase.
  • Objectivity of outcome: compare the statement “Improve service by providing an information system to respond to customer inquiries.” With “Able to answer customer queries last 2 monthly statements and last 60 days transaction over the phone.” Clearly focusing on the outcome brings more clarity and saves lot of vagueness and future disputes with your customer over actual intent. It is recommended that scope definition or project charter is developed in iteration essentially with customer involvement using an authorized document format.
  • Managing Scope Creep: This is a common problem where requirements are not clear and complete. Essentially this is due to incorrect interpretation of the requirements or due to requirement gaps in the scope definition. Sometime additional requirements come up after more clarity emerges or there are changes in stakeholder expectations due to changes in external environments. Therefore it is essential that your project plan has provision to incorporate and approve new requirements and modifications in existing one after careful consideration of impacts by project CCB (change control board) or governance board
  • Project deliverables: An internal deliverable is something that project produces as part of the project for internal use e.g. E-R diagram while an external deliverable is something that project team provides to the business users. I have seen some PMOs require that assigned PMs define internal and external deliverables (with agreed templates) and track at least phase by phase to ensure timely delivery and sign off with customer. This is a good practice and provides a level of comfort and confidence to the stakeholders as well.
  • Functional specifications: Scope definitions could be done using multiple techniques. This could also help in closing missed gaps. One of the techniques is to capture major functionalities by using decomposition. This could be done at the same time with data definition if possible. However if that is not practical the functional specification could provide the required data requirement.
  • Specify Assumptions: Each project initiatives have some or the other dependencies represented by assumptions. It is recommended that each of these assumptions are documented at relevant deliverables and followed up at the earliest. As the false assumptions could pose potential challenges to the project plans in terms of schedule milestones, resources, quality and cost constraints.

While most project managers focus too much on these two constraints however the biggest issue that results in to time as well as cost overrun is not able to manage scope of the defined project. Therefore, a tight definition and active management of project scope can not only deliver instant results but also relive you of unnecessary squeeze on your project resources.

Shyam Verma, PMP, ITIL
Program & portfolio Mgnt professional
LinkedIn:spverma. Twitter: Shammy1

New Year Resolution for Project Managers!



So its only few days before the New Year 2013 comes by, did you finally make your New Year resolutions? Well…so many people already made it. Now the big question, despite the best effort, how many of them would succeed! As per some analyst of hope syndrome, most of them would fail for the simple reason of unrealistic expectations. Interestingly, among New Year resolutions of 2011 the no.1 resolution for millions happens to be “Dieting”, I was wondering what would be top resolutions of a Project Manager in to New Year.

Here are few that I think would go a long way to bring about some sure positive changes if followed with some rigor.

  1. Track time and budget effectively: After all most project have schedule or budget as one of its success criteria so have a keen eye for these numbers. Set a regular recurring time slot to review them on weekly or bi-weekly basis and don’t forget to check the data source for any further data refinement needed. You may also plot these data points for graphical view to see emerging trends especially projects sensitive to budget, schedule or both.
  2. Use checklists: Despite advancements in processes or technology, we are ever busier by day and have to deal with lot of complexity and several critical tasks competing for our attention. A checklist is a very simple quality tool but one of the most effective one to employ for those critical tasks that need to be processed or can’t be missed.
  3. Meet Effectively: Some of the common best practices to focus for next year are pretty basic but also effective. My personal favorite is to send out your meeting material at least 1 day in advance not just before meeting start time! Another thing that helps is to have a well thought out agenda and expectations from the meeting participants so they come prepared. Keeping the meeting time short and discussion on tracking items too is a greatly appreciated
  4. Safety and security: With growth of technical advancement the safety and security concern to project personnel and assets is increasing too. This could be relevant to not only the core project team but the vendors and suppliers as well. So ensure your project safety goals and security policies are well laid out, your vendors and 3rd party personnel are vetted with right set of access, physical and IT security norms are followed per requirements. Don’t forget to set aside some time slot for any mandatory training too.
  5. Own your learning plan: Learning never stops in this highly dynamic world of today. As different sectors collide and collaborate at the same time, it is as chaotic today as never before. This demands continuous and exponential knowledge curve at the individual level. This is especially true since you can no longer depend on organizations to shape and take interest in your career goals. So one must have his or her career goals clearly defined based on the individual strength and personality.
  6. Set realistic goals: we often realize that in trying to accomplish too much we set up ourselves to fail by setting goals which are too hard to achieve. The solution lies in being objective and breaking these down to smaller goals. For example instead of setting a goal to say delivering all projects on time and on budget, why not breaking it in to better scope and cost management which ultimately leads to project delays and cost overruns.
  7. Networking: Don’t hang out just with your colleagues in Project management discipline. There is a greater awareness about importance of project management and many influential people like to hear about project management. LinkedIn and other professional networking sites are great places to build these networks.
  8. Volunteer More: This is my personal favorite and the reason for that is that there are so many organizations who cannot afford a project manager due to financial constraint but believe me several of them offer much more challenging projects with great learning opportunities outside the top sectors such as IT and construction.
Shyam Verma, PMP, ITIL
Program & portfolio mgnt professional
LinkedIn:spverma. Twitter: Shammy11