First you have to understand that timelines are not done until the project is done. Things move, estimates are off and sometimes people flake out. When you create a timeline you should expect it to be perfect. You should expect it to be a communication tool so that other projects can organize around you. It’s showing your expectations for when you will need resources and when you will hit milestones.
The key is to create a work breakdown structure. You need to understand everything that will happen between now and the end of the project. During this process you will get a clear idea of your scope and you should start creating that too. Talk to your experts, talk to your stakeholders and talk to everyone on and around the project. Get everything.
Once you have a good handle on what you need to do start assembling it into a network diagram. Ask what comes last. Is it a pizza party at the end of the project? What comes just before that, and just before that? I find working backwards to be helpful, but then I jump around everywhere and ask lots of questions. One question i find my self asking a lot is, “what is stopping us from starting this task today?” The answer will usually show you that tasks predecessor or get you to add something to the project. Another question that gets asked a lot is “Okay, we’ve finished this task, what happens next?” Make sure that the team is involved. Get estimates along the way. Push people to commit.
People are most motivated when they own their job. When they are making decision and those decisions are valued. You need to lop off a piece of the project that each individual can own and then hold them responsible for it. You need to make sure that they have responsibility, accountability and respect. Also, get their back when they need it. When mistakes are made resolve them quietly and move on. Fear of failure is a great short term motivator, but is severely lacking in the long term. Knowing that the team will help you when you need it is what pushes people to take risks, try new things and push hard.
Teams are complicated because they are made up of people who are complicated. Motivating a team is elusive because the people on the team all have different agendas. For some people getting home on time is more valued than anything you could offer them as motivation. For some people it is as simple as valuing what they bring to the table. Get to know the people on your team. Ask them what drives them and make sure they have plenty of it.
Different companies have different answers to this question and I’ve seen very few that fall in line with the Project Management Institute’s view point. In short, the Project Manager is responsible for organizing the team, communicating to stakeholders and getting the project done. A Project Manager should be able to initiate, plan and execute and close a project. They should be able to manage the scope, timeline, risks and the budget. In some organizations they are responsible for staffing the project, managing everyone on the project team and procuring hardware and software.
In some projects the procurement is handled by a procurement manager who may get all the hardware and software for the entire company. Staffing in a matrix environment is usually handled by department managers. But the project manager should be ready and able to handle any of these responsibilities.
In a company you have projects, lots of them, many of the projects are related in some way, whether by division or by project type. A collection of these projects would be called a program and is managed by a program manager. All of the programs in the company roll up into the company wide project portfolio which is lead by an overall portfolio manager. It’s possible to have only projects or projects and an overall portfolio depending on company size and the number of projects.
I’ve found often that designers and developers like to wait till they are completely finished and signed off on a project before publishing. This seem like a good idea and it gives the team all the time they need to make it perfect.
When one group waits till the last minute to show their stuff it leaves the other groups in the dark. This increases angst and reduces the gray area between project success and failure, making the project a raving success or a massive failure with nothing in between.
What if, instead of allowing your teams to churn on the project, you drove them hard to complete it in a very short time? I’m saying, cut the project in half, or a quarter and finish a 12 month project in 3 months. Sure it would be pretty crappy, but think of it as your first sprint in an agile project.
Creativity, idea generation and group involvement are the fun, team building, parts of a project. It’s the part of the project that makes us all want to get into this line of work in the first place. Get all the angst out in the first round, get the project in a place where it meets business goals, where you could launch it if you had to, then begin the churn…
By finishing early you reduce angst and increase the enjoyable part of the project.
Obviously this woks best for agile type projects, where the end product is not set in stone, but I propose that the same idea applied to a waterfall project would yield similar results.