Leadership

Beware of when "completed" activities aren't really completed


One of the primary responsibilities of a project manager is to assign work to team members and then monitor the work to see that it is completed on schedule.

It's important that team members understand the work to be completed, the estimated effort, the estimated cost (if applicable) and the estimated completion date. It's very possible that a team member will not agree with these estimates. And he or she may have a legitimate concern. No one likes to be held accountable for estimates on something in which they didn't have a chance to provide input.

I tried to acknowledge this concern by always giving the team members a chance to validate that the estimates were reasonable. If the team member didn't speak up, I assumed the estimates were valid.

After you assign the work, you need to monitor the work to make sure it's completed within expectations. There may be times when you encounter a situation where the team member says that an activity is complete when in reality it isn't quite done. This can happen for the following reasons:

• The activity should have been completed and the team member believes he needs just a short amount of time to complete it. He might say it's complete and then finish it up quickly, rather than deal with the consequences of the activity being late. This is a problem. The first time it occurs, you may need to provide some coaching. If it happens again, you might need to deal with the situation as the start of a performance problem.

• A deliverable is "completed" in draft form but not finalized and approved. The team member may say the work is complete, but when you check the deliverable you find it's incomplete or needs additional follow-up work. This may be a case of the team member trying to get away with the fact that the deadline date was missed. However, it may also be a legitimate misunderstanding of what it means to be complete. Just as with the prior example, the first time it occurs you may have an opportunity for coaching. If it happens again, it may be the sign of something more serious.

To avoid this problem, make sure that there is an approval process for all major deliverables, and that the workplan leaves time for the approval process and for rework based on feedback. Then there is no question that the deliverable is completed, because it has either been approved or it hasn't. The team member can no longer hide a partially completed deliverable, and there can be no misunderstanding as to whether the deadline date referred to completing the draft or having the deliverable finalized and approved.

34 comments
bright-side99
bright-side99

"you may have an opportunity for coaching", isn't that a tad condescending? In engineering, I believe the project managers are trained as engineers, which is why project management is a respected and needed function. In my experience in IT mostly it's a glorified clerical job. The project managers can't get their head around anything technical, let along providing me with coaching on what's involved with a task or how long it should take me. I think if this dicpline is to provide any value the practicioners need to forget about "coaching" people and learn about technology.

Junkhead23
Junkhead23

It is interesting how most technicians / engineers think a Project Manager needs to be technical in order to do his or her job. If an organization is setup correctly you would have Subject Matter Experts (SME's) assigned to each logical role. Example SME List with roles and responsibilities: Project Manger - Ensuring everyone is doing what they are suppose to be doing. Lead and Facilitate meetings and workshop sessions to obtain status updates, gather requirements, size and scope a project and develop and track the project schedule . Also, remember the Project Manager takes the brunt of everything related to the project so the Project Team don't have to. If he or she are a good Project Manager. Project Lead Technician - Responsible for ensuring that the technicians are doing what they are suppose to be doing. They conduct coding reviews, define technology architecture and ensure the development effort is being programmed to meet the business requirements. As a Project Manager I am highly reliant on these individuals and they are my right hand person. This individual may have 1 - 5 developers working under them. Business Analyst - Responsible for defining work flows, policies and procedures, and business requirements. This individual truly understands how to obtain information from the project champion, sponsor, or end users to develop sound requirements. They know what questions need to be asked and answered. This individual is my left hand and again I am highly reliant on them to ensure project success. They may have 1 - 5 business associates they work with to define what is needed for a project. By having clear and precise roles, good communication and a team atmosphere there should be no (he said - shes said) nonsense. It sounds like you do not have a good relationship with your current Project Manager and that is unfortunate. Maybe they have not defined what the roles should be as it relates to your project (Who knows). I do know one thing I value everyone on my team as long as they are doing what they are suppose to and reward them for there accomplishments. I hope this helps to provide you with a different opinion about Project Managers because we are not all bad. Best regards, Jay

wrlang
wrlang

It all depends on how you take the word coaching. Perhaps it is the wrong word, perhaps not. PMs can only really coach people in PM. I think that?s what was meant. Having been a mainframe systems programmer over a decade ago, I liked having PMs around to write up the fluffy status reports and handle the touchy feely communications so I could concentrate on the fun techie stuff. I?ve coached many a PM on techie stuff so they can communicate the issues well without dragging me into a fluffy status meeting. Now I?m more or less a PM. It?s up to the individual to prove they can do both technical and PM jobs effectively. Otherwise PM coaching is in order.

COBeals2
COBeals2

IT Project Managers DO spend a lot of time on clerical work; that is a function of the state of the tools today... and they are getting better. Yes, it can be wrong for the PMgr to tell the Tech Leader what they did "wrong" (in most cases)... but, think down the line, after a couple of projects, the PMgr has a set of Lessons Learned docs and some budget vs actual info on timing and dollars and risk that CAN be used to coach anyone who is trying to plan out a new project or bring one back on track.

fdaugherty
fdaugherty

I would suggest a few things: 1) Checkout the most popular downloads on techrepublic. Look for: 10 wording blunders that make you look stupidMany words have been so relentlessly misused, they've found their way into the mainstream and onto the pages of modern dictionaries. But there are still plenty of mistakes in circulation -- wrong words or nonwords that are bandied about out of ignorance or an attempt to sound extra smart. Check out this companion to "10 flagrant grammar mistakes that make you look stupid" to see if your pet wording peeves (or unwitting mistakes) are on the list. 2) Arrogance is the number one downfall of all tech people. Perfect example of arrogance is Dubya and his Iraq war. 3) Being extremely defensive shows a sign of weakness. Learn to listen to better understand the other person's position.

pmtk724
pmtk724

Dubya has nothing to do with this forum. Keep your politics to the appropriate sites. Try moveon.org next time you get the urge.

spencemeister
spencemeister

Interestingly enough, I found this discussion both helpful and amusing. I'm always amazed at how quickly things can degrade in a relatively anonymous forum where the consequences of being misunderstood are nil. People will say things here that they would never say to a colleague in any capacity. In my position I get to wear several hats, part BA, part technical, part PM. In addition, I get to work with people who have those exclusive roles. Some exude excellence. Some are smart as a bag of hair. Some are new. Some are unscrupulous, back-stabbing jerks (those are usually the business proponents though). It seems to me that the biggest challenge of the PM is often to maintain espirit de corps and encourage the team members to own the project. Whether it is going well or faltering for some reason, I always try to be helpful no matter which hat I happen to be wearing at the time. Eliminate the finger pointing and remember that if I'm not part of the solution, then I'm part of the problem. There's always more than enough technical hurdles to overcome. I don't need to heap personal hurdles on top of them.

meryllogue
meryllogue

It is quite true: Provide a relative measure of anonymity (sp?), and the flames go to full strength. Plus, I am always a little amused by (and draw some conclusions about) people who can take one bad experience and turn it into a "rule of thumb" by which to judge all others of that particular profession/race/class/group. As a PM (and a PMP), I know that my job and expertise is to facilitate decisions and expedite the project (and all that this entails). I don't make decisions... I help the team make the decision that is right for the project/company/client. (Being a little leery of being flamed, I hasten to add that "team" includes all stakeholders... anyong affected by, using, owning, contributing to, etc.) That said, I DO need to learn a lot about the technical aspects of the project, but only from a fairly high perspective, so that I can understand the issues, and can help the facilitation I mentioned above. I absolutely will not (and should not) try to become an expert. Instead, I should have a very clear "big picture" view. I know when I finally "own" a project because suddenly I have a clear vision of the project, where it is going, what it will take to get there, and I can just start driving it. On large projects that can take weeks or even months of digging, conversations, learning. But it does pay off. OK... now I think I am rambling, so buh-bye!

ShadyHouse
ShadyHouse

I am afraid that from where I sit ?BigOleJack? and ?BrightEyes999? seem to have a problem actually working for someone and do not consider themselves as part of a team working towards a common successful goal ie a project in on time, under budget, tested (working properly to specs), the end-users happy, and signed off. . Good technicians do not (necessarily) make good project managers. Indeed why waste the talent of a good technician and make them a project manager? The reason a PM will ask a technician for advice or guidance is because a technician is paid to be at the top of their particular technical tree and the PM is not. The PM is paid to have the focus on getting the project in. We have all met technicians where they will only answer the question put and should you not ask the right question then they will not give you the benefit of their experience. These self-centred ?people? could not care less about their colleagues or the project, only about projecting their images as super-intelligent beings. In the UK we have an expression for people refusing to join the human race, sorry I meant project team. The expression is FIFO (Fit In or F? Off). Oh, btw, I am a ?Technical Project Manager?.

bright-side99
bright-side99

Maybe they can sense the F..Off in your attitude, for all the folks who you deem not worthy of belonging to the human race (which to you is the same as your project team). They might be more willing to work on your exalted "team" if you were nice to them.

ShadyHouse
ShadyHouse

It isn't a case of "willing to work on the team" but just "willing to work". In my experience peoples' attitude/outlook in professional life mirrors the same in their personal life. So you are probably correct comparing (anyone's part of) the human race to a project team. (How I hated saying that you maybe correct). I can't help feeling that a lot of what is currently going on in this forum is misinterpretation of 2 versions of "english". Thanks but my exalted "Dream" project team is fully-staffed. As it is Friday we are ALL off up the pub for a bit of R&R.

Big Ole Jack
Big Ole Jack

Had you read my post properly, I was referring to project managers who had to bug the engineers for every single thing because in my opinion, they weren't qualified to be PMs'. I have no issues or problems working in teams, as I employ one myself, but what gets my blood boiling are so called "Project Managers" who waste everyone's time by not even having the basic technical skills to know how to put everything together and have to fudge dates and bug the technical folks with mundane and simple nonsense.

sindhu.sharma
sindhu.sharma

Hey,Frankly speaking a Project Manager who gets Dirty in the Project is not the right choice of Project Management,however vast his Techincal experience is. 1.Management calls for Maturity in terms of the Project Lifecycle and ensuring the focus and direction of the Project completion. 2. A Manager who gets downright dirty into solving Technical details, is not a Manager.He would rather be a Technician. 3.The Manager must forget that he/she is not there to play around with the nitty-gritty details of the Technical mess. 4. The Manager must remember that he is a part of the Team, and every member in the Team has a defined role to perform.His role is to GUIDE the Team to Project completion. 5. His Technical expertise should help only in Guiding when required to do so , and not whenever he so wishes. A Techno-Functional Manager is always an asset to any Project.This must be born in Mind always. 6. A PM should pave the way for the Technical Geniuses in the Team.He/She should provide them with a Vision and Motivate them enough to achieve it 7. He/She should step in only when the Team needs him/her Technical expertise, else he/she must focus only on the Big-Picture. 8. Most importantly, a PM Must Trust the Team's capability. BTW I am a Technical Manager too and above listed points are from my own experience as Team Member and Project Manager.

ShadyHouse
ShadyHouse

I'm only repeating your words. "Company"? "Freelance"? "Employees"? You implied that you are now a "company owner". I realise now - 1 man band. x

Big Ole Jack
Big Ole Jack

Who said I no longer do technical work? Your assumptions only serve to show the kind of judgemental being you are. I was stating what I experienced in the past, and you go making assumptions about me being a salesman? Sure I'm a salesman, but I'm also the project manager and senior engineer for any work that my company is contracted to perform.

ShadyHouse
ShadyHouse

....have a dog AND bark myself" 1) we've probably put your comments down as over-generalisation. (a generalisation in itself?). 2) your comments repeat your first posting 3) your comment highlight your basic mistrust of all (?) others and the inflated belief in your point of view. 4) learn to delegate and let them get on with it. Don't do the PM bit yourself, get on with the real thing of running the business. By the last comments you make about fudging dates and mundane questions probably means that you weren't very communicative in the first place. Join the team! Is that why you are no longer in the technical environment and became a salesman?

Locrian_Lyric
Locrian_Lyric

Which is the PM who *is* technical and micromanages. When I was a PM, I could keep up with the folks, but if they could tell me why there way was better, I would defer to their expertese. All I cared about was if the work got done and done well, everything else was useless detail to me.

raintree
raintree

And I like your FIFO expression. Hadn't heard that one before.

Big Ole Jack
Big Ole Jack

The guy had a broad picture of how thing works, but lacked detailed knowledge in anything specific or how to integrate all of this. More time was wasted on him bugging the engineers to pick their brains instead of getting the project done. A project manager that has to ask engineers about things he/she should know has no business calling him/herself a project manager.

Locrian_Lyric
Locrian_Lyric

A project manager's job is to make sure that a project gets done. You could, in theory, have a completly non-tech person running a project. All he needs to know are a series of yes/no questions, and the ability to drill down from there. Any issues? Any show-stoppers? On schedule? Soft deadlines met? Hard deadlines met? Anything to expidite? Any bottle-necks? From there... What are the issues? Are there any reccomendations to resolve the issues? Are there any issues that arose that you've resolved? If so what were they? What was the impact? Do you need additional resources? Are you still on schedule? What are the show stoppers? What do we need to remove them? Are there workarounds? Suggestions? and, of course, the most important thing a PM can do is stay out of the way.

raintree
raintree

I guess you should know. I'm sure there are some around but I don't know any IT project managers that don't have a background in IT. They know the nuts and bolts and have usually been the go-to person when they were building code or networks. They are the best people around to do coaching. If we "forget about coaching people" it's going to be real hard to keep the necessary teamwork going. I've seen a few projects where there was no coaching. Chaos doesn't seem to get much work done.

bright-side99
bright-side99

To me a coach is someone who can provide insight that I don't have - If someone worked as you described that would be fine. Unfortunately I haven't met any like that. The project managers i've dealt with - the one that wrote us about what to do with the "sequel" server. The one that kept two versions of due dates, one she gave me and one she'd change to please her boss thus making me the scapegoat for missed deadlines (she was too dumb to realize I could get copies of both schedules so got egg on her face). The ones that become advocates for the vendor instead their current employer, only to get a lucrative job with the vendor later. I'm not sure what background all of them have but they don't seem like go-to people, and are usually kind of lost with technology.

PMwannabe
PMwannabe

I think coaching is providing a person with insight that they don't have. In the example that the author uses, the team member was stateing that a task was complete when it wasn't. That team member abviously needs coaching (Insight). My goal as a project manager is to make sure the project runs smoothly and within the approved scope/time/budget. If there were dependencies on that team members task I would need to know that so I wouldn't have another discipline starting on a task that was dependent on this one being done. If this task is late I would need to know if it was going to put the project behind schedule/over budget, etc. Maybe that team member misunderstood the task or was doing something out of scope? The project manager needs to know those things. It's not necessarily to get anyone in trouble if they aren't done, it's to make sure the project is successful. Also, if the PM doesn't get accurate time estimates on this project and noone tells them any different, the PM is going to assume they are accurate and use those time estimates on similar projects. It's in the team member's best interest to give accurate time estimates and actual effort.

Wayne M.
Wayne M.

The best approach I have found is to steal from agile development practices and to divide work into small increments with defined acceptance criteria. First divide any large tasks into small steps so that you can track them on a simple scale of Not Started, In Progress, and Done. There is no need to have meaningless statements of "87.65% Done". Hint, you probably do not want to track this level of detail on your master schedule. You can role this info up manually to provide a percent complete at the higher level. Second, have an unambiguous definition of "Done". This way everyone understands what needs to be done to complete the task. Work is either Done or Not Done, do not accept any partially done work. You will not be able to check every task, so set up a weekly audit and validate one or two tasks with the team. Hint, it is usually most productive to have the team decide the acceptance criteria. The PM can recommend that the acceptance criteria be made more or less rigorous, but let the team own the definition. Avoid the trap of "90% Done." Define small tasks and use a binary criteria of Done / Not Done. Make sure there is a well defined acceptance criteria to determine if "Done" has been met.

ShaneHo
ShaneHo

Spot on, Wayne. Bite size (or should that be byte size) chunks are the only way. We had a rule-of-thumb in the Microsoft Operations team that a task duration was not less than a half-day and not more than 5 days. Anything more than 5 days made it difficult or impossible to verify completion, so longer tasks should be broken down into shorter sub-tasks.

donv
donv

Well sometimes programmers are under pressure to complete a task within tight deadlines which is never good. When when you ask if something is complete, you will always get round-about answers. A good way may be to break down tasks into percentages. So for example one task may be 5%, a larger task is 15% and so on. So if a programmer told you he had 20% complete, then you'd know he was completed the first 2 tasks. At least there's a programmer says he's 100% complete, there's no room to move since 100% is absolute. He can always say he's 98% complete. Any one use this kind of method before.

moore-margaret
moore-margaret

Our experience with a couple of clients is that they want to be down in the details of everything that's being done.....So we use the % complete method to inform our clients of where we are with each task. The info is published monthly so they never have to ask 'where are we on'......?

ShaneHo
ShaneHo

You say 'So we use the % complete method to inform our clients of where we are with each task'. What percentage do you use? Percentage of actual time elapsed? Percentage of hours worked? Percentage of budget spent?

gdeles
gdeles

Reporting complete is a slippery thing. I recently had a project experince extreme schedule creep and group strife when the PM allowed the "done" metric to requriments to be first draft submittal. He was being nice to the BA and being nice to himself by fudging that the project was on time. Hiding the requiments slippage just showed up as the development ending late because they started late. Of course the development team was put at fault for delaying the project. I fixed this relationship by defining "done" for requirments as in ready for development. Rather than zero time left, because realistically there is always some revision to the document. However the task must end. I also fix this problem by asking how much time is left rather thatn % complete. It is easy to lie to your self and other by being at 90% half the time.

ShadyHouse
ShadyHouse

..an amalgamation of (most of) all the mentioned points. "It seems to me that the biggest challenge of the PM is often to maintain espirit de corps and encourage the team members to own the project." aka FIFO. "Minimise project creep" aka don't give the client a RollsRoyce when they asked for a Jeep. Additionally provide a "shield" for the team to stop 'management et al' forever interrupting the team(s) directly with inane questions and directions. The job of the PM is to ENSURE that the job gets done, ie the project runs smoothly and that includes "gofering" (making coffee and getting the first, and last, beers in if necessary). Be lucky, be professional.

PMPsicle
PMPsicle

Good points. Five of the tricks I learned a long time ago are .... 1. Ask for weekly (written) updates (I use a tasklist so it's easy to complete). 2. Always define two stages of complete ... submitted and accepted -- with only the latter as actually complete. I then assign an arbitrary value (say 10% to the submitted/accepted task set). 3. Always distinguish between "actively working on", "actively cycling" and "awaiting next change" (this is related to the previous point). 4. Always ask "How long so far" and "How long to complete". Otherwise it will sit at the 90% point for a ridiculous length of time. 5. Always distinguish between different types of error. I've had specs turned over as complete (and accepted and coded to) which wouldn't work. It's a real pain to try to explain to the bosses that you delivered on what you were told to do, on time, on budget, on spec ... and now you need to do it over again because what you were told to do wasn't what you should have been told. (Not necessarily is it the BA's fault or under your control). A good issues reporting system helps with this.

Locrian_Lyric
Locrian_Lyric

There are cases when you have to go with "good enough". If there is a real need for something, sometimes you have to deliver 'ugly', and fix it after it's in production. Last project, we had phases, or "passes". We were under such a tight deadline that the business bought into "good enough", that was "Pass1". "Pass1" was the absolute bare minimum required to make it to production. "Pass2" was things needed, but could work without "Pass3" were "nice to have" things "Pass4" was "wish list" items.

Locrian_Lyric
Locrian_Lyric

Where I worked as a PM, we had the terms "done" and "done done". Done = working Done Done = fully functional, put to bed and no need to revisit.

Editor's Picks