40

Very short term solution: Based on my experience, there is always somebody who'll do anything for money. Money is the worst motivator ever, but if you are in trouble - such as losing a customer - you have to do something. If the money motivation works, think about the why and start thinking about hiring a new team, because they kind of put upon the situation ...


35

"but as we approach a deadline on a major product, we really should have all members dedicated to staying late to see it finished." If a PM is doing their job efficiently, this would be exactly the opposite of true. Your team should be working about the same amount of hours every week. If they have planned their project properly, and continually monitored ...


22

Start with a high-5 all around! :) Meet with your customer. Let them know you think you've completed the feature and give them a demo. Ask them if it meets their acceptance criteria. My bet is the customer will have some tweaks or changes now that they have seen it. By circling back to them right away, you've got a chance these changes can be made without ...


21

TL; DR Your question embeds some false assumptions about the linear nature of testing within an agile process. A mature agile team with cross-functional skill sets treats development and testing as intertwined activities rather than as sequential ones. You should strive to integrate development and testing so that they are not fundamentally separate work ...


19

TL;DR What is industry standard of how many projects one PM should manage at the same time? There's no such thing; individual projects vary greatly in the level of effort required to manage the project properly. In addition, each project management framework varies in how much overhead is involved. Therefore, the correct question is "How many hours per ...


18

Things that have prevented me doing any more than I'm contracted to do include: Habitual requests for extra time, if it happens every deadline, then the project manager is not pulling their weight. Lies. If you tell me you need it tomorrow, you'd better be using it tomorrow. If I ask you about it a week later, and you say you haven't looked at it, you can ...


17

Is it possible to sit down with the CEO and tell him exactly the same you told us? If he keeps sending adhoc requests to your teams, you don't have other choice than mark him as a risk and schedule the customer projects accordingly: less resources for the customer and more for the adhoc situations. Be honest with him, and discuss the situation. I don't ...


17

No matter how many times I read this, this line slaps me across the face "we really should have all members dedicated to staying late to see it finished." It is dripping with false expectations. When an employee accepts a job, at least in North America, a 40 hour work week is standard. Some overtime is expected, but only in exceptional situations. ...


16

There is a difference between "impossible" and "aggressive". Setting "impossible" goals, ones where there is almost zero chance of success, is a fantastic way to demotivate your team in the long run because teams are being set up for failure. I've been in companies where the team will provide an honest estimation that a project will take X months to ...


16

The only way to get the milestones accomplished on time is when the team sets either deadline or scope. If someone else does it (a PM), and the team did not participate in negotiation, they will simply think that the deadline is not their responsibility. You can force them to accept it, but they will be set up for failure and they will certainly fail. At ...


14

Of course it's a management technique. And at the risk of down-votes, it's used all the time. It's a function of Parkinson's Law, also known as the Student Syndrome - work expands to fill the time available. If a team is given two weeks to finish a task that could be done in week, it will take the full two weeks. And before anyone attacks, there are any ...


14

I can feel the frustration in your post. As someone who made the transition from a PMO to an Agile role I can understand both sides of the coin. Your question has multiple components which I will take in turn but all of them have effective communication at their core. Why are management more interested in logging hours? This could be a number of things ...


14

Person-month is politically correct synonym for Man-month. It's mean amount of work performed by the average worker in one month. So, if: project requires 12 persons-months of development time all team members do only pure development activity (i.e. they are telepaths and they don't need to spend time for communication with each other). [note: this is not ...


13

TL;DR You have already decided, a priori, that team member C is the problem. This is based on information you have not provided in your post. As a result, this appears to be a false conclusion that papers over a process problem that you (as the project manager) are responsible for uncovering. The Problem Given a task X, developers A and B would each ...


11

I feel sorry for anyone tasked with maintaining or altering any software created in such a manner. Is it possible to create software like this? Sure. You leave out the following things: Unit Tests Code Reviews Refactoring Architecture Enforcement A team that skips these steps, and gets very good at skipping them can deliver new software at amazing rates. ...


11

Asking the Wrong Question Is imposing “impossible deadlines” a Management Technique? Yes, it's part of the management framework henceforth known as Epic Failure™. It's right up there with flogging a dead horse, deliberately planning a death-march, and telling people to "work harder, not smarter." That doesn't mean it isn't practiced as a ...


10

Framework Overhead All frameworks entail some amount of process overhead. Some of that overhead is in the form of hours worked by the project manager, but some of it is a byproduct of delivering on framework controls and artifacts. The latter form of overhead is often significantly larger, since it tends to impact everyone on the project rather than being ...


10

Multitasking kills productivity. Task-switching costs can be deadly. What I would suggest is to make Management aware of the costs and risks of having developers working on multiple projects simultaneously. Even if for some magical reason task-switching did cost 0 time, why would you want to finish Project A and B in ten days, when you could instead focus ...


9

From what you've described, it sounds like the best thing to do is move on. The project involved you doing X hours of work for Y units of compensation. Since the project was cancelled before you started, that means you've done X=0 hours of work. Therefore, it seems justifiable that you would receive Y=0 units of compensation. If you're a consultant, your ...


9

Cone of Uncertainty Research in the software industry on the Cone of Uncertainty stated that in the beginning of the project life cycle (i.e. before gathering of requirements) estimates have in general an uncertainty of factor 4 on both the high side and the low side (Boehm 1981). This means that the actual effort or scope can be 4 times or 1/4 of the first ...


8

Interference of your planned work is part of the stochastic uncertainty of all project work and should be part of your estimates and targets, to which you alluded with the "extra padding" message. I would not recommend that you tell your CEO his requests will have to be sequenced with all the others. However, if you are able to show that lowering the ...


8

You are describing the difference between "work" and "duration". Work is in hours, and is typically the target number of hours that will be burned doing direct work for that task. Duration is a period of time, typically in days, in which that task is to be done. Therefore, you can have a task in which you estimate 40 hours of work, but you are estimating ...


8

There are some answers about dealing with the immediate problem. You should also invest some time into making sure you're not in the same boat again. I notice you say: the realities of the industry dictate that sometimes we can not finish everything that needs to get done within that time frame. Some questions I'd be asking: Who set the release date ...


8

From everything I've read, switching to a Results Only Work Environment results in an upswing in productivity. It tends to result in more hours worked too, but that's not the goal per se. In a nutshell, ROWE means that you stop managing hours and work location and instead manage measurable objectives and let employees control their own time and decide for ...


8

Focus on the goal, not the process. You have a project, you and your team know when it's got to be done. Everyone's agreed. Now if everyone is responsible for an aspect of that work, then it doesn't matter how long they work, or when, as long as the work gets done as agreed. It's only when those preferences for hours impact others that you need to worry ...


8

Quick answer: It depends. It depends on: Frequency: If you're having a daily meeting, sending the minutes one day later make it useless. Action Points: If you're dealing with several people that will follow the actions discussed during the meeting, better sending the minutes before having the other people doing anything. Otherwise, if the attendees carry ...


8

I recommend: Demonstrate your application to the customer often, and get feedback early. Break stuff down into small tasks that you are very confident about estimating time for. This is key. Focus on minimal functionality first - login, logout, visit home page, etc. before the real features. Use an Agile methodology. Talk to your client daily. Use software ...


8

I don't have any solid evidence - our projects are much longer. At one point I did work for a company that required timekeeping to the 0.1 hour range. That lasted about six months before the accountants told the company President to stick to his own swim lane. Speaking as a PM, I would have the following concerns about timekeeping with a precision of 0.5%....


8

Why is management is more concerned of JIRA burndown chart than of following Scrum values in project development? 3 common reasons for this type of behavior are: Lack of trust Poor understanding of Agile methodologies; still thinking in waterfall terms Delivery Team is not meeting commitments Why do some members of the team not like to log hours in JIRA ...


8

What is important is not really how long these events take, but if you get the desired results from them. For example, the Daily Scrum could take only five minutes because everyone is just giving a task board update and largely ignoring each other, which would of course be bad. On the other hand, it could take 5 minutes because everyone talks throughout ...


Only top voted, non community-wiki answers of a minimum length are eligible