This is a guest post from Utpal Vaishnav.
This is a guest post from Utpal Vaishnav.We take utmost care to protect our computers, laptops and mobiles from viruses but have we ever thought that the projects we are managing can also be infected by viruses?
Such viruses can lead to severe project health problems such as unmanaged expectations, missed deadlines, client-relationship issues or sometimes overall business disasters.
Here are seven deadly viruses and how we can combat them and protect the projects we’re managing:
- Improper engagement models: In the modern onshore-offshore software age, most clients opt for hourly rates based model just because it initially looks like dramatically cost effective. The major problem with this model is that both the parties are trying to achieve the opposite. Project sponsors are interested in getting the project completed in the least possible time while offshore companies are trying to pocket few more hours. This is a typical example of win-lose relationship. As a project manager, you need to make sure that in project management ‘Project’ is the subject not ‘hourly rate’
- Poor requirement gathering: A lot of projects start with high level, vague and incomplete requirements. This leads to the cases where developers build whatever they feel appropriate without having any specific knowledge of the client’s business. As a project manager, you need to make sure that the requirements are accurate, measurable and exactly as per the project sponsor needs.
- Unrealistic deadlines: Many project sponsors manage the projects through ‘pushing’ the developers by setting unrealistic deadlines. Most developers cannot handle such pressures well and focus on just hitting the numbers at the cost of quality. Result is disastrous end-product. As a project manager, you need to make sure that developers get enough time to accomplish the tasks. You need to take a stand and proactively convince project sponsors such that they set realistic deadlines.
- Feature-creep: Feature-creep means uncontrolled change in the project’s scope. Typically, it consists of addition of new features without corresponding increases in resources, schedule or budget. Such feature-creep can result in project-overruns. As a project manager, you need to implement tight change control and make sure that any change in scope is accompanied with change in resources, schedule or budget.
- Deficient or no testing in place: Many projects do not have liberty to pass through all the stages of SDLC. Project stakeholders sometimes do not pay attention to importance of requirement gathering and testing part. As a project manager, you need to make sure that:
- Requirements are frozen such that measurable test plans can be created and acted upon.
- Adequate time is allocated to unit testing, integration testing and most important user acceptance testing.
- Testers are trained to understand the purpose of testing and make the application bug-free
- Ineffective communication: Ineffective communication can lead to surprises and frustrations – which often results in a de-motivated team – and the project is in a mess. As a project manager, you need to make sure that communication plan complies with the basic function of communication – which is coordination of actions. You should also state clearly who will talk with whom and about what type of actions.
- Inferior Leadership: Project without leadership is like an airplane without pilot. In order to reach the destination (which in our case, successful project delivery) pilot has to perform his job really well. Similarly, as a project manager, you need to make sure that:
- Cultural sensitivities are taken care of especially when many projects are executed in onshore-offshore mode.
- Requirements are concise, clear and actionable and most important frozen.
- Project team is happy and ready to attack on the tasks assigned to them, every single day.
- Internal and external delivery milestones are met.
- Stakeholders are updated with project status reports
- Proper Risk-control is in place.
Have you encountered any other such kind of viruses? If yes, please enlighten the whole project management community of PmStudent by adding comments below.
(If you liked reading this article, please visit Utpal’s blog for more articles on this subject.)
No related posts.
{ 20 comments… read them below or add one }
Thanks Utpal! Tying together 2 and 5, it’s also important to ensure requirements are testable.
Otherwise, how will you know what “done” looks like? Glen has commented about his firm’s use of the IMP (Integrated Master Plan) to help define what “done” looks like, and it’s important to keep this in mind with all requirements and work packages too.
Thanks Utpal! Tying together 2 and 5, it’s also important to ensure requirements are testable.
Otherwise, how will you know what “done” looks like? Glen has commented about his firm’s use of the IMP (Integrated Master Plan) to help define what “done” looks like, and it’s important to keep this in mind with all requirements and work packages too.
Hi Josh,
I totally agree that definition of “Done” is the MOST important factor to ensure that requirements are testable.
The old saying, “If you don’t know where do you want to go, no road can take you there!” – suits perfectly here.
More to that, definition of “Done” provides us to begin with the end in mind – which is one of the most powerful habit.
Best Regards,
Utpal
Utpal,
Add to that
“The units of measure of ‘Done’ must be mneaningful to the customer.” Then you’ve got the basis of increasing the probability of success for your project.
Great post for all those business executives who are the source of many of the troubles on IT projects
Hi Glen,
Thanks for adding a very important perspective. Businesses (and thus, project management) are all about delighting customers. And the “done” must be meaningful to the customer.
Have a fantastic Friday.
Best Regards,
Utpal
Utpal,
As it turns out every customer I know bought a “capability” to doing something useful.
The measure of “done” is usually in units of “needed capabilities” for software projects. But the same for flying to the moon or mars, delivering power from a nuke plant, and most anything someone paid money for.
Hi Josh,
I totally agree that definition of “Done” is the MOST important factor to ensure that requirements are testable.
The old saying, “If you don’t know where do you want to go, no road can take you there!” – suits perfectly here.
More to that, definition of “Done” provides us to begin with the end in mind – which is one of the most powerful habit.
Best Regards,
Utpal
Utpal,
Add to that
“The units of measure of ‘Done’ must be mneaningful to the customer.” Then you’ve got the basis of increasing the probability of success for your project.
Great post for all those business executives who are the source of many of the troubles on IT projects
Hi Glen,
Thanks for adding a very important perspective. Businesses (and thus, project management) are all about delighting customers. And the “done” must be meaningful to the customer.
Have a fantastic Friday.
Best Regards,
Utpal
Utpal,
As it turns out every customer I know bought a “capability” to doing something useful.
The measure of “done” is usually in units of “needed capabilities” for software projects. But the same for flying to the moon or mars, delivering power from a nuke plant, and most anything someone paid money for.
I always find it interesting when people write about ONE type of project but fail to acknowledge that. Although some of Utpal’s comments are general, many are specific to software development. To me, this is similar to saying “let me tell you about problems you might have with your car,” and then discussing the importance of waiting for the “okay to start” signal that is only used with a diesel engine.
I’m also somewhat concerned about some of the specific comments:
– An hourly rate can be perfectly appropriate if the contract contains the appropriate controls. I have clients in the Middle East who use off-shore organizations on an hourly-rate basis to do most of their design work.
– All projects start with high level, vague, and incomplete requirements. That is what the project life-cycle is for.
– The discussion of unrealistic deadlines is overly simplistic. Sponsors often have a reason for wanting something done by a particular date. Developers will, on occasion, take extra time that they don’t really need. The PM’s job is to educate both sides, not to assume that the sponsor is being unreasonable.
– The comment about frozen requirements conflicts with the comment about strict change control. To quote Harold Kerzner: “frozen requirements are a lot like Frosty the Snowman. They are both myths, and they both melt when subjected to heat.”
– Six of the seven items listed under “leadership” are, in fact, management responsibilities.
Duncan
William R. Duncan, Project Management Partners
Primary author of the original version of “A Guide to the Project Management Body of Knowledge”
Director of Certification, asapm
Bill,
Aside from title description, Capers Jones field research shows vague and incomplet requirements are the number source of cost and schedule overruns. His categories are broad. They do not include construction, but do include SW and HW in a variety of government and commerical domains. Possibly construction is different.
Jones and the assessments of the programs we work in defense have shown that unrelaistic dedlines – irregardless of the desires of the “customer” are the seceond sources of OTB (Over Target Baseline).
While to term “frozen” elicits many images, requirements stability is essential for any non-trival projecct. Emerging or unstable requiremenst is equivalent ot “rework,” Which of course means OTB.
So I not sure in your post how a solution can be conjctured in the presence of unrealistic deadlines, vague and incomplete requirements.
So independent of the general phrase – the project life cycle, how specifically are the issues you’ve presented addressed in the projects you manage?
I always find it interesting when people write about ONE type of project but fail to acknowledge that. Although some of Utpal’s comments are general, many are specific to software development. To me, this is similar to saying “let me tell you about problems you might have with your car,” and then discussing the importance of waiting for the “okay to start” signal that is only used with a diesel engine.
I’m also somewhat concerned about some of the specific comments:
– An hourly rate can be perfectly appropriate if the contract contains the appropriate controls. I have clients in the Middle East who use off-shore organizations on an hourly-rate basis to do most of their design work.
– All projects start with high level, vague, and incomplete requirements. That is what the project life-cycle is for.
– The discussion of unrealistic deadlines is overly simplistic. Sponsors often have a reason for wanting something done by a particular date. Developers will, on occasion, take extra time that they don’t really need. The PM’s job is to educate both sides, not to assume that the sponsor is being unreasonable.
– The comment about frozen requirements conflicts with the comment about strict change control. To quote Harold Kerzner: “frozen requirements are a lot like Frosty the Snowman. They are both myths, and they both melt when subjected to heat.”
– Six of the seven items listed under “leadership” are, in fact, management responsibilities.
Duncan
William R. Duncan, Project Management Partners
Primary author of the original version of “A Guide to the Project Management Body of Knowledge”
Director of Certification, asapm
Bill,
Aside from title description, Capers Jones field research shows vague and incomplet requirements are the number source of cost and schedule overruns. His categories are broad. They do not include construction, but do include SW and HW in a variety of government and commerical domains. Possibly construction is different.
Jones and the assessments of the programs we work in defense have shown that unrelaistic dedlines – irregardless of the desires of the “customer” are the seceond sources of OTB (Over Target Baseline).
While to term “frozen” elicits many images, requirements stability is essential for any non-trival projecct. Emerging or unstable requiremenst is equivalent ot “rework,” Which of course means OTB.
So I not sure in your post how a solution can be conjctured in the presence of unrealistic deadlines, vague and incomplete requirements.
So independent of the general phrase – the project life cycle, how specifically are the issues you’ve presented addressed in the projects you manage?
Bill, you might have missed the title of the article – which states this is about software project Management. I agree with the rest of the comments from Bill and respectfully disagree with some of Utpal’s points in this article.
1)”major problem with this model (T&M) is that both the parties are trying to achieve the opposite.” This comment assumes that both parties are in the business of cheating each other. I am sure there are some of those. But it will not be a sustainable model. As a offshore service provider, I will work honestly and try to add value to the client. As a Client, I will be need to cautiously trust my service provider and collaborate with them. In my mind, fixed bids are more challenging than T&M. Estimating accurately (I understand it is an Oxymoron) is the biggest problem. Once you have the estimate, you will have to live by that. Client now will have to go thru lot of hurdles o make any real or perceived changes. The major ingredient of the T&M type of project is the mutual trust between client and service provider.
2) Poor requirements gathering: First of all, I disagree with the term gathering with requirements… if at all requirements were as easy as “gathering” the leaves from my yard in November!. That aside, you are right, requirements needs to be clearly stated. But how and when do we do that? Incrementally elaborating requirements by working collaboratively with users or user representatives is the best way in my opinion.
4) Feature Creep: As Bill suggested, this assumes that we are “freezing” the requirements that we “gathered” at the beginning of the project. Once again, a process that elaborate and build the product in an iterative incremental way is superior in my books.
5) Testing: agree with the article and your comments later on. Testing takes time and a definition of done is important.
Disclaimer: I am a proponent of Agile/Scrum. So if any of my comments sound like it, it is intentional! Please send your thoughts.
Manoj
Bill, you might have missed the title of the article – which states this is about software project Management. I agree with the rest of the comments from Bill and respectfully disagree with some of Utpal’s points in this article.
1)”major problem with this model (T&M) is that both the parties are trying to achieve the opposite.” This comment assumes that both parties are in the business of cheating each other. I am sure there are some of those. But it will not be a sustainable model. As a offshore service provider, I will work honestly and try to add value to the client. As a Client, I will be need to cautiously trust my service provider and collaborate with them. In my mind, fixed bids are more challenging than T&M. Estimating accurately (I understand it is an Oxymoron) is the biggest problem. Once you have the estimate, you will have to live by that. Client now will have to go thru lot of hurdles o make any real or perceived changes. The major ingredient of the T&M type of project is the mutual trust between client and service provider.
2) Poor requirements gathering: First of all, I disagree with the term gathering with requirements… if at all requirements were as easy as “gathering” the leaves from my yard in November!. That aside, you are right, requirements needs to be clearly stated. But how and when do we do that? Incrementally elaborating requirements by working collaboratively with users or user representatives is the best way in my opinion.
4) Feature Creep: As Bill suggested, this assumes that we are “freezing” the requirements that we “gathered” at the beginning of the project. Once again, a process that elaborate and build the product in an iterative incremental way is superior in my books.
5) Testing: agree with the article and your comments later on. Testing takes time and a definition of done is important.
Disclaimer: I am a proponent of Agile/Scrum. So if any of my comments sound like it, it is intentional! Please send your thoughts.
Manoj
Hello Bill,
Thanks for expressing your views. Please find my response below.
The title of this post says that it is related to “software” project managers. So, I guess it is explicit from the beginning that I’m going to talk about Cars with Diesel Engines!
Regarding the hourly rate model, I agree with your statement that “An hourly rate can be perfectly appropriate if the contract contains the appropriate controls.” – from that perspective it is totally fine. My tip is to ensure that project manager takes necessary actions when focus moves from project to “saving hours” – which in many cases happen when the engagement model is hourly rates based. I did not mean that ‘hourly rate’ model should not be used but I meant that if it is used, it should be handled with specific care.
I mentioned “A lot of projects start with high level, vague, and incomplete requirements…” ( I believe “A lot of” does not mean “ALL”) – Focus here is to ensure that requirement gathering process is good using project-life-cycle, obviously.
I know that sponsors often have a reason for wanting something done by a particular date. With all due respect to that, I believe, it does not necessarily mean that project will be accomplished just because they need by a particular date. If it is practical and feasible, it will be otherwise not. At the same time, I agree that the project manager should track developer activity such that he or she does not take more time than they don’t really need – this is a good addition for the readers. I also agree that project manager’s job is to educate both the sides but when any side is being unreasonable (which in considerable [not "all" again!] cases project sponsors especially in some types of offshore-onshore model) , they need to do the needful.
To me, there is a distinction between frozen requirements and change control. A good change control will ensure that any new requirements are also frozen before it enters ‘execution’ mode. By frozen requirement, I mean that we have a system in place which prevents the project to get into chaos due to changes while in the execution – I have seen a large number of projects being managed really well if this is in place.
Regarding Project leadership and project management, several points are management related – however I think that project management is a blend of leadership and management capabilities and that distinction becomes less important if project manager ensures what is mentioned above. However, from the lens you saw it, it could have been communicated the better way.
Bill, I once again appreciate the time you put to comment and expressing your views – Such discussions can show good insights on the subject from different perspectives and help the project management community at large. I look forward to communicate, connect, learn, unlearn and relearn from your experiences and thoughts and go to next level.
Best Regards,
Utpal
Hello Bill,
Thanks for expressing your views. Please find my response below.
The title of this post says that it is related to “software” project managers. So, I guess it is explicit from the beginning that I’m going to talk about Cars with Diesel Engines!
Regarding the hourly rate model, I agree with your statement that “An hourly rate can be perfectly appropriate if the contract contains the appropriate controls.” – from that perspective it is totally fine. My tip is to ensure that project manager takes necessary actions when focus moves from project to “saving hours” – which in many cases happen when the engagement model is hourly rates based. I did not mean that ‘hourly rate’ model should not be used but I meant that if it is used, it should be handled with specific care.
I mentioned “A lot of projects start with high level, vague, and incomplete requirements…” ( I believe “A lot of” does not mean “ALL”) – Focus here is to ensure that requirement gathering process is good using project-life-cycle, obviously.
I know that sponsors often have a reason for wanting something done by a particular date. With all due respect to that, I believe, it does not necessarily mean that project will be accomplished just because they need by a particular date. If it is practical and feasible, it will be otherwise not. At the same time, I agree that the project manager should track developer activity such that he or she does not take more time than they don’t really need – this is a good addition for the readers. I also agree that project manager’s job is to educate both the sides but when any side is being unreasonable (which in considerable [not "all" again!] cases project sponsors especially in some types of offshore-onshore model) , they need to do the needful.
To me, there is a distinction between frozen requirements and change control. A good change control will ensure that any new requirements are also frozen before it enters ‘execution’ mode. By frozen requirement, I mean that we have a system in place which prevents the project to get into chaos due to changes while in the execution – I have seen a large number of projects being managed really well if this is in place.
Regarding Project leadership and project management, several points are management related – however I think that project management is a blend of leadership and management capabilities and that distinction becomes less important if project manager ensures what is mentioned above. However, from the lens you saw it, it could have been communicated the better way.
Bill, I once again appreciate the time you put to comment and expressing your views – Such discussions can show good insights on the subject from different perspectives and help the project management community at large. I look forward to communicate, connect, learn, unlearn and relearn from your experiences and thoughts and go to next level.
Best Regards,
Utpal
Hi Manoj,
Thanks for stopping by and adding your comments. I honor your respectful disagreement with some of my comments
My views on your comments are:
1) “Major problem with this model is that both the parties are trying to achieve the opposite.” (This includes Time and Material (T&M) and Dedicated Resource Model – both) -By this I did not mean that both parties are in the business of cheating each other. I guess cheating business is something else. For example if we play a game of chess, both the players are trying to achieve the opposite (win over the other player) – it does not mean they are in the cheating business!
As an offshore provider or a client, anybody who wants to be in the business for longer would choose to be honest and add or get value to/from the client. This is what businesses are for – This is an ideal situation but what if it doesn’t happen? Then situations feel like attacked by a virus.
I also agree that Fix Bid projects are more challenging than hourly based model and estimating accurately is a great challenge. However I think we should discuss about this model in a different conversation at this takes us out of the main point for now.
I also 100% on the same page with you that hourly rate based model works best when mutual trust exists between the client and service provider. But what if for whatever good or bad reasons, deficiency of trust is in place? Title of this post talks about those situations…dealing with viruses. In this context, viruses mean unexpected situations or problems that can impact your project adversely.
2) I can understand how dissentful it would be for an agile/scrum proponent to talk about requirements and gathering. Answer to “How and when” to gather the requirements clearly is “In any conversation you are gathering the requirements!” Incrementally elaborating the requirements is a great option if we have liberty to practice agile in the project management process – from that context it is one of the best way. However, when agile is not an option, things are different.
3) The comment reply I gave to bill would answer your comment about Feature Creep.
4) Thanks for agreeing. You can achieve success only if you know “How success looks like” – This way, definition of “done” is one of the most important factor in testing and project success at large.
Manoj, I appreciate your willingness to confront with some of the comments in this article. I believe disagreements if taken in positive manner, lead to overall betterment of each individual involved and I hope we both are taking it that way
I look forward to share knowledge and learn from your experiences and become instrumental (in both of us) going to next level.
Best Regards,
Utpal
Hi Manoj,
Thanks for stopping by and adding your comments. I honor your respectful disagreement with some of my comments
My views on your comments are:
1) “Major problem with this model is that both the parties are trying to achieve the opposite.” (This includes Time and Material (T&M) and Dedicated Resource Model – both) -By this I did not mean that both parties are in the business of cheating each other. I guess cheating business is something else. For example if we play a game of chess, both the players are trying to achieve the opposite (win over the other player) – it does not mean they are in the cheating business!
As an offshore provider or a client, anybody who wants to be in the business for longer would choose to be honest and add or get value to/from the client. This is what businesses are for – This is an ideal situation but what if it doesn’t happen? Then situations feel like attacked by a virus.
I also agree that Fix Bid projects are more challenging than hourly based model and estimating accurately is a great challenge. However I think we should discuss about this model in a different conversation at this takes us out of the main point for now.
I also 100% on the same page with you that hourly rate based model works best when mutual trust exists between the client and service provider. But what if for whatever good or bad reasons, deficiency of trust is in place? Title of this post talks about those situations…dealing with viruses. In this context, viruses mean unexpected situations or problems that can impact your project adversely.
2) I can understand how dissentful it would be for an agile/scrum proponent to talk about requirements and gathering. Answer to “How and when” to gather the requirements clearly is “In any conversation you are gathering the requirements!” Incrementally elaborating the requirements is a great option if we have liberty to practice agile in the project management process – from that context it is one of the best way. However, when agile is not an option, things are different.
3) The comment reply I gave to bill would answer your comment about Feature Creep.
4) Thanks for agreeing. You can achieve success only if you know “How success looks like” – This way, definition of “done” is one of the most important factor in testing and project success at large.
Manoj, I appreciate your willingness to confront with some of the comments in this article. I believe disagreements if taken in positive manner, lead to overall betterment of each individual involved and I hope we both are taking it that way
I look forward to share knowledge and learn from your experiences and become instrumental (in both of us) going to next level.
Best Regards,
Utpal
{ 1 trackback }