Michelle Labrose, one of 25 women recognized most influential women PMs in the world by the PMI or the Project Management Institue, had this to say about reasons why Projects fail.
Of possible pitfalls, she mentions five reasons, namely:
1) Falling victim to feature creep
2) Multi-tasking too much
3) Over-scheduling people resource time usage
4) Not eating right (healthy diet)
5) Not moving and breathing (a.k.a. no exercise)
Now as I was reading Ms. Labrose’s article , I was prepared to catch possible technical issues, concerns and maybe even a little wisdom that are purely PM-related. What I saw, instead, was more a reminder of what we, as PMs, should be doing… heck, there’s no secret to what she said – and yet… as I pondered the five reasons, I thought ‘yeah…. How often do we; in the span of getting too busy, forget these five very simple, yet obvious tips?” I certainly did a few of these things at one time or another.
The article is short (about a page and a half when printed), and it assumes readers and PMs know what she is talking about – heck, you really need not be a PM to know what she is talking about as Ms. Labrose’s areticle is not too technical – in fact, I would suspect that she writes this way to make her ideas easy to digest. It’s also short, as I suspect, she writes to a presumably busy crowd. Goring back to said article; the original text can be viewed at http://searchsoftwarequality.techtarget.com/news/column/0,294698,sid92_gci1344193,00.html?asrc=SS_CLA_306147&psrc=CLT_92 and I do hope that by sharing it here, I get more people – primarily, those not in her usual reader’s circle, to read it. I , on the other hand, will just try and expound a bit on what these five are – and maybe in the process, share some personal ideas.
Item one – feature creep, is obvious… or is it? As I mentioned earlier about the items in this list, needs to be revisited every time one talks with a client. It will be so easy for any client to ask for small favors – seemingly innocent and harmful ones, even ones that seem simple enough to do. To them, it seems simple, and yet… any PM worth their salt should first look at the project deliverable’s scope. A few questions need to be asked here before blindly committing to a ‘yes’ or ‘sure’ reply. Mind you, I’m not advocating a total stop to the practice of giving some ‘goodwill’… after all, it’s one way of building a positive relationship with our client. I just want to suggest a cautionary move on anyone’s part when confronted by this situation.
So how are these questions connected to feature creep? A) Is this task really as simple as it sounds? And in connection to that; B) what is the scope of change or adjustment to this request?; C) can the project afford to insert this change with respect to the budget and schedule – important factors both, if one is to be professional about the entire thing. And lastly (for now), D) if I can’t give it, will this really damage my working relationship with the client? These, I shall address in the succeeding paragraphs – and if I get too carried away, maybe even succeeding articles – at least I’ve got something to write.
Lets start with some obvious reminders… all projects have a schedule to keep – and these well educated estimates rely on a lot of experience to create… both from the PM, the PM’s colleagues and the project team members themselves. When does feature creep come in? Its when things have already been agreed upon, when the budget and schedule have been ironed-out… then suddenly, in the middle of the project’s execution, the client thinks – maybe it would be good if we had this
So how do we handle schedule creep? Well, as we may know – its easy to say ‘yes’ in an effort to please the client – then suffer the consequences alter on – and by doing so, we ensure that pitfall number 3 will happen. Not exactly a wise move on the PM’s part.
A) Is the task as simple as it sounds?
Here’s an idea in helping resolve this. Forewarned is forearmed – and to help warn us of just how much a task is being asked of us via this innocent request – we need to look at how much this idea’s inclusion will change our work scope. Here’s an example… a simple change of the screen’s display can be easily done by anyone – but we need to make sure that this change, when addressed, will not indirectly affect other user’s screens from the same system –and form adjacent systems that the client is using – that does not grab you, how about a different way of storing data we already have? Sounds easy to say, right? Is it easy to execute? Maybe not.
It is for this reason that PMs are expected to be ‘experienced’ – meaning they’ve hopefully had the prior experience of having done a s similar project in the past – not necessarily as a PM, but as a project member who is privy to how things went – and can repeat successes, or avoid pitfalls. But experience can likewise be a collective work – as mentioned earlier, as more progressive organizations have adopted best practices within their procedural aspects – specifically to ensure adapting best practices and avoiding pitfalls… in other words, learning from the experiences of others. In line with this, we go to…
B) What is the scope of change beings asked?
To answer this, we need to trace back how far (or deep) this change will be – what components (detailed work groupings) will be affected, and how long it will take us to do the job. If the project has some kind of requirements-traceability documentation or table (matrix)… wherein a work being done can be traced back to the necessary requirement it is fulfilling, then this can be very helpful in tracing back what tasks will be affected / added, if we accommodate one simple change or addition. If we know exactly what requirements are being asked of us and how it will affect our scheduled tasks – we will be able to see how much additional work this may entail us.
C) Can the project afford to insert this change with respect to budget and schedule?
Larger projects may have set up a steering committee – and it is the role of this committee to sift between all the wants – and separate the needs. They are a filtering mechanism, and will normally be composed of people from the client-side… specifically able to understand the project’s scope, and the priorities within the tasks being done. If a request is asked – it should be forwarded to the steering committee, who will then consider the validity and importance of said request. Smaller projects, on the other hand, may simply have to rely on an individual – but this individual must still be someone of the client-side, whom the PM can talk to about these possible additions being requested.
This is my sneaky way of saying – don’t decide. Its not your project… you’re just managing it – but they (the client) will be stuck with it later. So any changes… no mater how seemingly beneficial, needs to pass through a protocol for deciding if the suggested item is indeed important and upon realizing that… know when it is best to schedule the creation and implementation of said change. We can suggest… but it will have to be decided on their end. Keep it that way – and if approved, quite naturally, a scope and schedule change will be necessary… and this is our safe bet that changes made are essential, recognized as officially part of the new scope.
Now, most of us will probably think – well isn’t that what we do anyway? Yes… but the danger of a feature creep is that it looks so inconsequential to have to pass through such a protocol that we’d might as well just add it without the hassle of having to attend all those steering committee meetings. Again, if it’s not official and documented, it may not be recognized – and if it’s a reason for delay later, it is the PM’s fault. Lastly, if you need some encouragement to avoiding feature creeps by making sure all these things are recognized and documented, simply remember... you might not be able to ask for compensation for services rendered in connection to work not properly approved and documented.
D) If I can’t give it (what is being asked) – will this damage my working relationship with the client?
Personally – yes. At that particular instant, the client will feel disappointed – but if the non-application of such suggestion can be presented with valid reasons, I see no reason why the client will not see it as a professionally acceptable reason. Especially if it is explained to them that the item being requested is deceptively simple, and giving it will possibly affect the timely completion of the task.
Remember, it would be so easy to say yes – and in a situation where you have no valid reason to say no… you might just as easily say yes (hence the need for answering question #1). If there is a steering committee, then the committee will have a resolution - and whether it is a ‘go’ or ‘no go’, you simply quote their decision and abide by it. So you can’t be seen as responsible for such a decision.
What’s worse, in some parts of the world – like Asia, saying no might culturally speaking, be connected to being insensitive or rude. This is not true… what is to be avoided is the possible loss of ‘face’ (wherein the client is embarrassed for their idea being seen as not worthy, and in connection to that – the possible treatment of others making them feel not worthy). So one easy way to do this is to have your discussions in private – if the feature addition can’t be done, only you two know of the failed initiative. No face lost there.
If you really feel bad about it, and would want to show your client that you want to help, borrow a page from customer-relations practitioners about giving a soft ‘no’, meaning you give them the ‘no’ and the reason why it can’t be done – but… you are ready with an alternative suggestion of thins you both can do. This way, it does not feel like there was finality to the discussion, but rather than end there, you are now exploring other options. One’s where both your hands aren’t too tied down. How is this done? You might start with saying “We can’t do this… but here is what we can do…” and explain your counter idea.
Feature creep is not easy – and PMs who would love to have a competitive advantage and impress their clients are often times too cavalier in giving in to these requested items - but remember that any added feature, and additional request given may indeed score you some brownie points with the client. Just make sure that said brownie points are not used up in meetings explaining why the project is delayed or getting too expensive. Other times, giving in to the request at tone time may be seen as a go signal to give in to the same thing in the future. So remember to make sure… in case you are giving in to the addition; despite the possibility of it being a project pitfall, you make sure the client knows this is a favour to them – and not something that is necessarily repeatable in the future.
Some PMs will even say (more so in cases where there is no steering committee) that it is a business decision and they, as PMs are within bounds to approve or give such a feature creep… well, forgetting for the moment that such a thing is tantamount to a scope change (albeit, being asked by the client) I hope that the PM in this instance has appraised the team that more effort has just been added to possibly an unchanged budget, because I forsee longer working hours to catch up with the added work… or the need for more people to join the team – which includes the time heavy selection and hiring process, project and task expectations setting meetings, adjusting to the project environment, and… exactly how much time do we have? Just saying…
By the way… if this is a feature creep, be well aware that it is going to normally be ‘gratis’ work – unless a scope change is approved. So, be careful about just disrupting the project’s timely outcome on something free. Like I said, a soft no might best reconsider doing what is being asked as part of the project’s next phase (if there is a next phase).
Feature Creep more so a daunting a situation for ‘First time’ projects by your team to any particular client who really want ot make a good impression with the hopes of getting additional business. Remember this advice… you shall be well remembered for brining what you promised to do, at the promised time… you won’t be given concessions for adding what was asked for, then renege on delivering the promised product when expected, instead of that, here’s another thing I learned with some of our Eastern-bloc counterparts – they say no… (as they are known to be more straightforward there) but try to do the feature anyway. That way, the client does not expect the feature, and is pleasantly surprised to see it as part of the end project.
With feature creeps just, well… creeping in, you (and your team) will end up harassed with more work, sometimes wondering why you agreed to such a concession in the first place. What’s worse, your project team members might be wondering if it isn’t too late to abandon ship - as your record as a credible PM is tarnished. Your reputation as a good leader may likewise vanish. Your team sees you as a ‘yes’ person – not able to draw the line when necessary, and saying no when they have to.
Understandably, many people are queasy to say no to a client… but in reality, if approached in a ‘soft no’ manner, the client may be reasoned with, and may even be appreciative of the PM’s candour. Plus, said client, will feel comfortable in realizing that their PM knows what they are doing… having properly explained why it might not be that easy to grant a seemingly easy request – nor why it is not possibly to their project’s best interest to add such feature now.
So, in a nutshell, Know what is being asked, know your schedule’s realities and limitations. Be professional… chummy is good, but in business, professionalism will be an important factor for any organization trying to make a lasting impression. You want to be seen as being dependable and competent, not someone who says one thing… then does something else. So hold off with your ‘yes’ until you have a better understanding of what it is the feature creep being asked for really entails, project-wise. If your client does ask you for something not in the agreed scope, you may, in a polite way, ask to study said request first and get back to them in a few days about your answer.
Since this entry is already looking to be real long, I’ll just continue this discussion in part two… where I will focus on why multi-tasking may not be so good after all.










