Making project commitments - Setting the realistic timeline at a very early stage

Have you ever had a fear of making commitments for things which can only been seen after months or years? Have you ever fallen in the situation that you and your team have to work hard for weeks or months to meet the deadlines? Have you ever been failed in meeting the deadlines?
These questions are actually something happening daily to the Project Manager (PM) and without the right method a lot of the answers “YES” could be found for these questions.

1.       Introduction

To overcome the above fears, we need to have the right method for making commitments which I’m going to present in this article. Besides, we also need the right tool to make sure we will meet what we committed which I presented in the recent post Earned Value.

One more thing, the method which I present here is one of my practices which I have applied for several years on many projects. I hope it could work for most of you.

OK, let’s see how it looks like.

2.       Background

One of the very first steps PM has to do is Estimation. PM has to estimate the total effort or total cost after he finalizes the Project Scope. So, after having the number of man-days (or man-months or whatever unit) what’s next? It’s the milestones! Or it’s the commitments! This is the most important thing client wants to know.  Basically, my practice will be based on two tools, the Historical Database and the High Level Schedule.

Picture 1: Method of making commitments

3.       The case study

This case study assumes that we estimated one project and arrived at the total effort of 90 man-days. I used Microsoft Project (MSP) as a tool to do high level scheduling. So, it is expected that the reader should know how to use MSP at a basic level.

3.1.    Historical Database

Using organizational historical database: to break down the effort distribution and to know how much effort it will take for each high level work package of the project. With the given 90 man-days, the distribution would look like:

High level work package	Distribution	man-day
Requirement	8.00%	7.2
Design	16.00%	14.4
Coding & Unit test	43.00%	38.7
Test	16.00%	14.4
Deployment	2.00%	1.8
Customer Support	4.00%	3.6
Project Management	10.00%	9
Configuration Management	1.00%	0.9

Table 1: Effort breakdown by high level work packages.

Using bench marking from the industry: with the effort of 90 man-days there is a minimum, maximum and optimum duration for it.

Max duration (calendar-month)	5.29
Optimum duration (calendar-month)	3.67
Minimum duration (calendar-month)	1.47

Table 2: Minimum, maximum and optimum duration.

There are some sources below which tell us how to arrive at these numbers. If you feel difficult with manipulating these sources, email me and I’ll give you my defined template.

·         http://www.spr.com

·         http://www.qsm.com/FPGearing.html

·         http://www.ifpug.org/discus/messages/1778/7498.html?1135791269

·         http://www.ifpug.org/discus/messages/1778/7498.html?1135791269

·         http://www.ifpug.org/webforum/discus/discus.cgi?pg=prev&topic=1751&page=4745

3.2.    High level schedule

Using high level schedule will give us an overall picture of how the project timeline will be. Moreover, MSP (or any similar tool) can automatically calculate the timeline from the input effort which give us more visibility to make the commitments realistically. 

Step 1: Bringing the breakdown work packages (from table 1) into MSP with some notes:

·         Creating corresponding milestones for the work pages which have deliverables.

·         Entering Work in day (MSP uses hour by default)

·         NOT caring the time yet, it will be considered in step 2

·         Doing something with layout to have the convenient view as below:

 

Picture 2: MSP with high level work packages

Step 2: Resourcing.

With each kind of work package, we should know which kind of resource we’ll need together with the quantity. However, two important factors below must be considered when assigning resource at this stage.

Resource availability: with a month of 22 working days, not all resources will work enough 22 working-days (they may have vacation plan, they may be sick when doing the project, or they may take some hours off for doing interview in one another company J ).

Putting a reasonable number of resources: 9 women can't make a baby in a month. Similarly, sometimes, putting more resources to a work package won’t reduce the duration.

OK, so let’s get back to our case study and I’ll assign resources basing on my expert judgment as below:

High level work package	Resource	Quantity	Availability
Requirement	BA	2	80%
Design	TA	1	80%
	Dev	3	80%
Coding & Unit test	Dev	5	80%
Test	Tester	2	80%
Deployment	Dev	2	100%
Customer Support	Dev	2	50%
Project Management	PM	1	30%
Configuration Management	CMO	1	20%

Table 3: Resource availability

Step 3: Assigning resource to the high level schedule.

We put the numbers from table 3 into the MSP got from picture 1. As the result, MPS will automatically calculate the duration for all work packages. Moreover, it will also calculate the linked milestones to each work package.

Picture 3: The complete high level schedule

Step 4: Making commitments

From this point, we can know when to deliver what basing on the milestones. However, be careful before making commitments. Depending on the risk assessment on each work package, we should add an amount of time buffer correspondingly. In MSP, we can do this by adding lag time to the milestones or using Deadline value for each milestone.

4.       Points of discussion

I have presented this method a few times and most of the times I received questions relating to some common topics as below. So, I’d better list them out here.

About using resource availability: please be noted that there is no change on the total estimated effort at all. The point here is to exclude the time which people plan not to work on the project such as vacation, sickness, etc. So, it is to make our high level schedule or our commitments to be more realistic. In case, you don’t know who will be assigned to the project, I hope you have an organization rate to apply for all resources. Otherwise, my recommendation is using 80%~85%.

Assigning a developer with 400% workload: This is just for utilizing MSP to calculate the duration from the input effort. In the case study, we have 5 developers with 80% availability so in total we have 400% availability. Alternatively, we can assign 5 developers and each has 80% availability.

Using resource availability and time buffer at the project level: when running the project, there will be no buffer at all for particular tasks and the resource availability for doing particular tasks should always be 100%. We apply these techniques at project level to mitigate the risks, not at the task level.

5.       In summary

Using the Historical Database will help to know which high level work packages we need to do on the project and the size of each.

Using MSP to create a high level schedule will help to arrive at the milestones and then the commitments.

Using the industry benchmarking will help to double check whether our commitments have potential risks in term of effort and delivery time.

Completing the high level schedule will also answer how many resources and what kind of resource we need in each period of times. This is also called a staffing plan.

Service-Based Leadership of Project Managers

If you google with keyword “Service-based Leadership” or “Strategic Leadership”, you will see many articles and discussions are available and helpful there. In my post, I would like to summarize my knowledge and experience gotten in last 6 years of management and state some tips from my standpoint.

The term “Project Managers (PMs)” in this post is only mentioning to someone (not all) I’ve met and worked in last six years.

 Part I: Tips of Service-based Leadership of PMs

 1. Service-based Leadership by recognizing what value should be delivered

Many mornings when I have just started my work, PMs dropped me many emails asking for new templates used in their project management and how to fill meaningfully into forms and templates to send to clients. They would be willing to bring benefits to client, but don’t know how to perfect them. 

Many times, I have gotten plans and reports said more than ten pages of text without filtering that they were sent to all stakeholders from PMs for distributing information. I had to face difficulty and took a lot of time in finding out exact information I needed in hundreds of reports & plans each month.

A procedure which I realized was established unofficially for PMs using:

• Look for a template at company and a sample to illustrate how to use this template
• Try to fill all data in forms or reports.
• Send them to all stakeholders related.
• Wait for feedback 

The most important step was ignored in this procedure is “identify what useful information should be distributed to particular clients and isolate them in different forms/reports”

Once I stopped working; thought about what stakeholders were expecting and what PMs were doing; especially what value of company training to PMs in bringing the best services to clients. In reality, every level and position had different expectations for what they would receive, however PMs delivered unexpected ‘products’ - both software deliverables and information. Fortunately, QA team was responsible for testing software deliverables before releasing them to stakeholders. However, how about information distributed? Was all (information) put in one (report) although the stakeholder was only looking for a small piece in this one? I also recognized that the training heavily focused on teaching how to use template and paying attention on importance of process and standards which company following instead of teaching PMs how to complete forms and to distribute information base on stakeholder’s expectation. By this lacking of training, many PMs rigidly used project management framework, standards and processes, they have been running projects “robot-ly”

A service-based leadership PMs should start the work by understanding the needs and expectations of stakeholders (not only software deliverables but information distributed). The PMI also focuses on Stakeholder Management as key element of Project/Program Management; it interacts with many other processes during project’s being executed.

In many organizations I’ve known, after applied many techniques as survey, interview, focus group, brainstorming…to get understanding about expectations of stakeholders, they’ve stated Voice of Customer in Quality Function Deployment [1]  (Figure 1); have monitored it carefully and have used it for post-deployment survey to measure the degree of  stakeholder’s satisfaction.

  By understanding the needs and expectations of stakeholders, PMs can isolate what should be delivered to stakeholders and how to maximize value of delivery. Ex: If a PM identified what specific stakeholder looking for and he provided concisely and precisely information in report, that means he just minimized waste time/ effort of his client and just maximized business value for his client. This looks very simple but it is exactly service oriented management

 2. Service-based Leadership by setting win-win relationship
I’ve gotten many discussions with PMs at my company on what win-win relationship between the organization and clients. Most of them were on the same page to say that win-win relationship was project should be in budget and clients satisfied on what they had received. I totally agree with this point but it is not enough on my standpoint.

From report of Jim Johnson, Chairman of Standish Group that in typical software systems 64% of features are never or rarely used in reality. This means clients (outsourcer) must pay 100% costs of full features for only 36% value of delivery which they receive. I don’t think this is win-win relationship.

We don’t hope to perfect them to 100% usage. However, to maximize this number as well as possible, PMs should change mindset in accepting change requests. Don’t avoid changes. Look at change request from business view of client. And try to control changes in budget and time of project. I believe that PMs have own ways. And this also explains why Agile methodology is more and more popular.

                                                   Figure 1 Quality Function Deployment

Even a survey is more effective if it is conducted after a long time product’s feature is deployed to production environment, instead of conducting at release period.

We all understand that demands increase will push supply increases and only when business value of client is maximized, their demands will be growing up.

 3. Service-based Leadership by having another view about Stakeholder Management
3.1. An another look at client management
        Easy to say that a PM is working for his company but client really is person whom he is serving. The client is paying money for services of PM (who does not join directly to develop product). Besides, duty in coordinating/managing project work, the client always hopes that a PM as their representative to provide truly information about performance of team and to reduce Total Cost of Ownership ^[2] and Total Cost of Utilization ^[3] while still keeping project runs effectively and efficiently.

Client also wants PMs to manage performance of team members in best way they can. Remove barriers, provide appropriate tools, acquire good performers and stop service of poor performers who have no desire to improve.

Stakeholder management (I’m mentioning to client management) is not only to satisfy the expectations but PM also should play role as client’s representative to protect their business.

 3.2. An another look at team management
Employees are serving boss or boss is serving employees? A question is followed with many arguments. To answer this one, we should know what is objective here. My standpoint, I believe that boss should serve employees while employees are serving client because final objective is the boss needs to create environment where all employees feel totally committed to doing great job. 

The same with team management, according to “Road to Destination 3”, I completely agree idea about “Some people may feel proud when being promoted from a project team member such as a developer, a QC or so”, even some experienced PMs are also feeling proud of their positions and try to exercise power for highlighting their positions. This thought completely is wrong. The PMs or team leaders are not different from other members whose common objectives are to get project success and benefit for organization. They have power in hand to support and drive the team to success. It means they are serving the team performance.
 4. Service-based Leadership by having both reactive actions and proactive actions

Many PMs complained they hadn’t got authority to do this one or that one in leading and managing others, especially in Agile Projects or ODC Projects where PMs are mostly taken out power of management. However, “Successful leader don’t not attain their leadership positions by waiting for superiors to appoint them”.

The PMs should start project, initiate process; reach for more responsibility and look for more opportunities for themselves by serving the interests of clients. PMs are not only reactive in project management but also should be proactive in helping clients to identify risks, to improve everything in projects and give clients advices & constructive feedback even if PMs are not in charge of these things or are limited by authority

An example to illustrate this idea, if a PM is working on Agile project, almost tasks are assigned to team members directly from client. However, PM should proactively consider if any team members are lacking necessary skills to propose a short training to client and always keep an eye on their performance instead of waiting results from client.

5. Conclusion

The size of project success is determined by size of quality of service. It is the valuable intangible asset because the trust of client cannot be bought with money that this is acknowledged by quality of service that in there PMs are playing the most important roles.

[1] Quality Function Deployment: A method to transform user demands into design quality, to deploy the functions forming quality, and to deploy methods for achieving the design quality into subsystems and component parts, and ultimately to specific elements of the manufacturing process

[2] Total Cost of Ownership: A method used to help make investment decisions. TCO assesses the full Lifecycle Cost of owning a Configuration Item, not just the initial Cost or purchase price.

[3] Total Cost of Utilization: A method used to help make investment and Service Sourcing decisions.

6. About Author

 

Nhat H. DO, PMP

Software Development Director at TRG-Enclave

Public Profile on LinkedIn

Road to Destination 3 - First time leading a team

Team Leader (TL) is an interim position from which people will promisingly move up to the position of project manager and farther. So, it is a very good opportunity for people who want to move to the path of project management. However, there will be some challenges when you’re first time doing something which you’ve never done before. From a person whom most of people love to work with, you can make them love you much more or you can become a stress maker for them.

1.       Introduction

Via Road to Destination 1 & 2, I have given an overview of the career path. On the road to your expected profession, being a TL is one stop. In the world of software development, there’re two kinds of leaders: Technical Leader and Team Leader. In this article, I’ll almost focus on the Team Leader (TL). Being a TL, you start doing some work of project management such as estimating, scheduling, monitoring tasks of team members and so on.

Figure 1 Preparing for being a team leader first time

I do believe that most of people who are assigned to the role of TL have shown a very good performance and had very good achievement in the technical development work. However, being a TL you need more than strong technical skills.

2.       Problems

Mike has just been assigned to a new project as a team leader. In the former projects, he always completed his development tasks on time or even early. He also contributed some good solutions for the projects as well. As a team leader, he does not receive individual tasks as before, but the whole module to develop with his 4 team members. He begins with listing out what need to be done and estimates time before committing to the Project Manager. After that, he meets each team member to verbally explain and assign the tasks. He also gives his expected deadline. Mike begins seeing difficulties when running the team: ·         Some members couldn’t complete work as schedule ·         The team doesn’t care much on the project objective; they don’t really care that the delay of their tasks causes the delay of the team’s commitment. ·         Mike is not confident with whether he can complete what he committed on time. ·         Because of pressure, Mike sometimes loses control and speak/complain to his team members loudly.

Above is a common situation which I often see at new TLs. Some people can learn on the job and become matured with this role, but some others seem to be struggled for long time. To shorten the time of learning, I’ll share some of my thought on what a new TL needs to prepare to be ready with this new role. It includes preparing your thought as a TL, essential hard skill and essential soft skills.

3.       Preparing your thought as a Team Leader

Not being a boss but having new responsibilities: Some people may feel proud when being promoted from a project team member such as a developer, a QC or so. They may misunderstand and think that they now have power to ask people to do whatever they assigned. If I temporarily put aside the skill called leadership skill which is one of the most difficult soft skills, then the common responsibilities of a team leader will be:

·         Doing a similar task of a team member.

·         Planning tasks for the team.

·         Tracking tasks of the team to make sure the whole team work on schedule and within budget.

That’s all for a start! Thus, the team leader just simply takes two more responsibilities in comparing with a normal team member.

Driving team’s reputation:  Because you plan tasks for the team you should know the strength and weakness of each member so that you can have suitable assignments for them. The success or failure of the team will much depend on your planning.

Being a good example: If you don’t follow what you talk or if you don’t follow the organization’s rules and policies, your team won’t listen to you. So, be prepared to be a good example (or a standard) for what you want the team to follow. The leader does the right thing, all team members tend to do the right thing and the consistence will come.

4.       Essential hard skills

As said above, as a team leader you will have minimum two new responsibilities, planning and tracking tasks. In order to do this well, you will need two more hard skills:

·         WBS & Scheduling: This is for planning tasks. I won’t explain WBS in details here, you can quickly ask uncle Google for this concept.

·         Monitoring & Control: This is for tracking tasks. You should start learning and applying Earned Value. If the team size is small or the amount of team work is not big, you can just ask verbally for the task status daily. But I suggest the principle for this as below:

o   A task shouldn’t take more than 16 hours. If it takes more, you need to break it down.

o   A task should only have two statuses: 0% and 100%.

5.       Essential soft skills

With more responsibilities of being a team leader, you will be surprised when receiving so many requests from many stakeholders such as from team members, project manager, client, functional managers etc. At the same time, beside your individual tasks you will also need to take care of the team. If you don’t organize well, there will be a mountain of tasks in front of you, always. This is why you will need the two skills below:

·         Time Management: practicing this skill will help you to control your tasks, not let the tasks to control you. I have my own saying “I always have a mountain of tasks, but I always have time”. By understanding and practicing well this skill, you will see that although tasks keep coming, but none of them or very few of them are urgent or at high priority.

·         Effective Meeting: obviously you will need to meet your team for reviewing schedule, reviewing status, discussing project issues etc. Practicing this skill will help you to pay minimum time to get maximum result. Ineffective meeting will waste a lot of time and so … money.

Social activities: When loving you, people take only 3 from your 7 mistakes but when hating they will round it up to 10. This is why “social activities” is one of the important factors to help you to succeed in being a team leader. You need to accompany the team. Smoking, having meals, drinking, playing games, playing sport etc. are some examples.

6.       Conclusion

The skills and the thoughts which I have given here is only a start point. Depending on how much you involve in managing the team and the project, you will need to learn more beside the technical skills (or hard skills) which you have gained. Good luck!