15

I am a project manager of a development team. Oftentimes, the deadline for the development project is not met.

About my team:

  1. I have 4 people in my team, and they are older than me.
  2. Sometimes I feel uncomfortable instructing them because they are older than me
  3. 2 people are only part-time freelance workers.

About my project:

  1. I'm developing a Web application using PHP; it's a recruitment site.
  2. I have 1 month to finish that project.

About me:

  1. I'm a new project manager. I was a developer before this.
  2. My job is to make the schedule, create the project flow, and create the project environment.

Problem:

  1. Deadlines are missed because we're adding many functions in that Web application.
  2. We have people with not-so-good skills for that project.
  3. The people who are freelancers will only have a little time to work.

Questions:

I've tried talking to my team about the missed deadlines, and they say they need more time to study the development environment. We choose to use FuelPHP as our development framework.

  1. How should I communicate with them so they can follow my instructions?
  2. How to giving spirit for my team?
  3. What should I do with the people who don't have good skills?

Thanks to the people who have given me suggestions.

20

1.How to communicate with them so they can be follow my instructions?

The team shouldn't be following your instructions, they should be following a plan that they contributed to and signed off on. As a PM your job isn't to do or manage technical work, it is to make sure that the people who are responsible for the doing and managing are following the plan.

What you need are clear accountabilities for the deliverables.

2.How to giving spirit for my team?

Continuously engage them in the project from the start, keep them informed and make sure you listen to and work with them to resolve issues when they come up. Let them know why the project is important, what the business value and vision are. Work with them to plan the project rather than presenting them with something you came up with. Let them come up with estimates and present a feasible plan to the project sponsor. Then go back to the team to amend the plan if it is not acceptable. This is a lot of work up front but saves you problems on the back end.

3.What should I do with the people who don't have good skills?

Account for this in your planning. Factor in extra time/resource costs in their deliverables to address the learning curve, more than the usual number of bugs, etc. Document this as a risk to schedule/budget/resources/quality/benefits and put it in front of your sponsor. If your project is high enough of a priority you could use this to get leverage to get more appropriate resources, or at least change project constraints to account for the resources you have.

  • For What should I do with the people who don't have good skills? The best strategy IMO here is to get the right resource than accounting for "newbies" in the planning. This never works if newbies are outnumbering the others and leads to disaster. Those time costs don't work. Unless off course these newbies are those that are very smart and can break the novelty in very short time. – bhantol Apr 1 '15 at 17:05
13

When I was a new project manager, I had trouble separating my previous role as a developer from my new role as a project manager. What compounded my problem was that it was a gradual move, as the project I worked on started out as just me as a developer, and eventually led to me working as a project manager and leaving the technical details to the team.

Developers Choosing Technologies

I've tried talking to my team about the missed deadlines, and they say they need more time to study the development environment. We choose to use FuelPHP as our development framework.

You mention that your team is a bit inexperienced and that your team is using a framework that they may or may not have chosen. Since they're older, it's possible that one or more of your team members are more experienced as developers but simply lack experience with this framework.

Experiment to see how experienced the team really is:

Instead of choosing the framework yourself, involve the team in the decision. Since your job as a project manager involves documenting and making stakeholders aware of risks, the chosen framework represents a risk that the team could eliminate, simply by choosing a framework that is both right for the project as well as for the team.

In fact, as a project manager, creating the environment may not be your job. Instead, delegate this job to the team. This will allow you to focus on taking their estimates and creating and managing the schedule.

Deadlines Missed Due to New Features:

It sounds like some stakeholder in the project keeps adding in new features. Is your team estimating these features? Are you extending the project deadline as a result?

If someone keeps trying to add new features, you'll want to discuss this with the client and your managers. They'll need to decide which is more important, a timely delivery, or a recruitment website with all of the bells and whistles.

Part-Time Workers:

Your schedule should take into consideration that not every team member is a Full Time Equivalent employee (FTE). Instead, when creating the schedule, you'll need to take this into consideration. For instance, if you have two freelancers who both work only 50% of the time that the full time employees do, then you have a total of 3 FTE employees.

If your schedule goes over the deadline, the answer is simple. You must talk to the client and other stakeholders and do one of two things:

  1. Extend the deadline.
  2. Cut non-essential features.

Good luck!

10

Redefine the Problem

You list several problems that you believe make your projects late. Specifically, you said that:

  1. Deadlines are missed because we're adding many functions in that Web application.
  2. We have people with not-so-good skills for that project.
  3. The people who are freelancers will only have a little time to work.

These may be legitimate risks or project issues, but they are not the real problem. The underlying problem is that your job as a project manager is to manage risk and provide project visibility to senior management. On-time delivery is an organizational responsibility, not yours alone.

When risks or process issues impact a project's schedule, your primary job is to raise the visibility of those issues and the level of schedule risk to management so that they can make informed business decisions about how to proceed. That may mean fixing the process, canceling the project, or making changes to the project goal or team team composition. The decisions are ultimately theirs.

Managing Risk

As a project manager, part of your job is to identify and manage risk. Here are some ways you can do that.

  1. If you are missing deadlines because of scope creep, you need to manage project scope more proactively. No one can meet deadlines when the "definition of done" isn't well-defined.
  2. If your team doesn't have the required skills to complete the project, you need to request training or additional team resources from senior management. Making the request is your job. Providing the resources is their job.
  3. Matrixed teams frequently have poor performance. Task-switching overhead, part-time resources, and unfunded mandates are not elements of a successful project. Again, it's your job to identify requirements, estimate resource needs, and request a sufficient level of dedicated resources from management to accomplish the project's objectives.

Conclusion

To be successful, you will need to clearly identify your role in the project's planning and ongoing management. In addition, you need to involve your organization's leadership appropriately to manage schedule risk in ways that make sense for the company.

10

Great answers before mine!

Let me add this: I see the biggest driver to your schedule woes is feature creep. If you focus on nothing else, focus on this. When features are added like this, you get a new timeline against which to measure your schedule performance. If you are not enforcing an appropriate change process, then being on time is near impossible.

The other contributors about which you wrote, in my view, are quite normal. These are sort of organic risks of all projects, ie., variable skill sets, variable resource allocation. These are simply inputs into your estimation and risk processes, such that you build in the schedule you need and have some contingencies in reserves.

Schedule is ALWAYS variable. Sometimes you'll be on time, others ahead of it, and still others behind it. That is normal variability caused by common cause. Trying to control that is futile. Feature creep, however, is a disease on the project and it needs to get cured. Change is good and definitely entertain new features, but build in the impacts to a new baseline schedule and budget. Instead of one month, you get 1.5, or even 2 months...all of a sudden, your team is not late any more, or is late within a tolerated variance level.

  • 1
    Yes - really must agree with this. Scope Creep is the biggest project killer there is. Stakeholders should sign off on requirements way down the line before design stage. New requirements should be discussed with a view to phase 2 or readjusted time/cost - the furtehr into the project the more it should be pushed to a new phase and/or the more it will cost the project. Manage that, manage expectations, manage the plan, and most other things manage themsleves. The other thing to mention here is that estimates should contain contingency for slippage - at design this can be 50-100% – Wolf5370 Aug 23 '12 at 17:51
  • "Schedule is ALWAYS variable. Sometimes you'll be on time, others ahead of it, and still others behind it." - this is a good point. Scheduling is just trying to predict the future, and that is hard to get right. – Robert Grant Oct 8 '17 at 13:38
8

Prioritize, prioritize, prioritize.

One month could be considered a very long time, or a very short time for such a project -- depending on the scope.

So take the scope (ie. "features"), and list items according how their importance.

Start at the beginning. Do one thing at once.

This sounds obvious, but oftentimes developers will start "a little bit of everything" all at once.

Devs need to start one feature, get it 100% working in a production environment, and only then should move on to something new.

Be Agile

This is part of the Agile methodology, and ensures that you have a working deliverable all the time.

If you follow this, after a month, you'll have something. It might not have every feature that you originally planned, but the ones you've done will work.

In theory, you could deploy the site at that stage, then continue working on the less important features. Which is much better than having nothing to show at all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.