If there’s one thing I learned from projects, it’s this…

They’re on track until they’re not.

And once they get off track, there’s no going back. They either spiral out of control or get stuck, the last 10% effort taking longer than the first 90% combined. 

You see, project management is theoretically easy. Start your project, define your project, launch your project, control your project, and close your project. Five easy steps with volumes of books written about each, explored and experienced by hundreds of thousands (if not millions) of project leads and project managers worldwide.

In practice, however, it’s one of the most challenging aspects of business. 

Why?

In part, because it takes years of experience to get a group of people pulling in the same direction to accomplish a bigger goal. Furthermore, every new project is a trek into the unknown. Finally, project management sits at the intersection of customer needs, business goals, and technology—three disciplines that are agonizingly difficult to merge.

And while I can’t guarantee your future success on any given project, I can share with you some words of wisdom from 10 years of experience managing projects. Let’s start by looking at the past:

Lesson 1: Don’t Let Past Successes Lull You into Future Failures

Years ago, I sat face to face with my CEO. With a host of successfully run projects under my belt, I was confident, arrogant perhaps, that everything would work out for our current project.

My CEO was not so convinced.

Our customer was incentivizing us with a $200,000 bonus to finish ahead of schedule, and I had just dropped some bad news: The project might be delayed.

In retrospect, the project was at risk from the get-go. After a year of running hard, it was becoming apparent that our planning didn’t set us up to finish the race. Like an ill-prepared marathon runner, I had hit a wall and there was little I could do to push through to a satisfactory finish.

Our sales team skillfully bought us a few additional weeks of buffer, still saving us the opportunity for an early bonus payout. And so, with a new date in front us, I remained confident.

My CEO only had to say one thing to snap me back to focus: “You’ve run a series of successful projects until now, but those don’t have anything to do with this one, and this one is failing. You have your new project date, but that’s because sales has a good relationship with the customer, not because you’ve run a tight ship. You see the difference?”

Those last few weeks we scrambled hard to make our date. The customer was happy, our business was $200,000 fatter, and I had another lesson under my belt: Don’t let past successes lull you into future failures. Instead, combine those past successes with any past failures, no matter how small, to learn and improve (more on this below).

2. Know Where You Are Daily (But There’s a Trick)

As the old saying goes, “projects slip one day at a time.”

It couldn’t be more true. Small slips, uncalculated risks, unforeseen complications slow execution down incrementally. At first, an hour here or there doesn’t seem to matter. But if one thing is for certain, it’s this:

You never get that time back.

Minutes add up to hours, hours to days, days to weeks, and before you know it, your CEO is in your office telling you sales had to speak with the customer to bail you out because you suck.

This is why you must track where you are on a daily basis. You have to know where you stand before you drift so far off you can’t find your place. But there’s a trick, and it’s the most important trick I know to keeping your project on track:

Don’t worry about how much time you spent on something, worry about how much time is left.

Each task will carry with it some beginning estimate. Some estimates will be high… most will be low. For years I spent time worrying about how much time was spent on an 8-hour task, keeping my project chart up to date. What good process taught me, later on, is that it didn’t matter if I had spent 6 hours on an 8-hour task if there were still 10 hours of work remaining.

Tasks change as we learn things, as we uncover new complexities, as we reveal their true nature. Updating each task with the amount of work time remaining is the best way we can truly know where our project stands on a daily basis.

Ultimately, it will allow us to make appropriate adjustments early instead of scrambling at the end.

3. Empower Your Team

A good team knows what to do and when to do it. A great team is empowered to succeed.

What does it mean to empower your team? It means giving them control. It means letting them define as many aspects of the project as possible.

They are the ones doing the work after all. Is it really fair to tell them what to do AND how to do it?

Sure, if you do, then you can be sure that things will be done exactly your way. But your way may not be the best way. Your way may not take into account different strengths and weaknesses of various team members.

By empowering the team, they take ownership of the project, the tasks, the communication, each other. They encourage each other to succeed, they pick up each other’s slack, and they focus on getting the job done instead of focusing on doing the job exactly the way you want it done.

How do you empower your team?

Start by asking your team who will take responsibility for each task in your project. Let them choose what they are going to do and how they are going to do it. You may feel the need to step in if you see them heading down an unknown path, but don’t. That’s not empowerment, it’s micromanagement. Not only is that demotivating, but it will also discourage them from being creating and taking calculated risks in the future.

4. Eliminate Obstacles

The best thing I ever heard a boss say to me is, “what do you need from me?”

That boss understood that it was my job to do the work, and it was his job to eliminate any obstacles I was facing. Put another way, he cleared a path and got the hell out of my way.

In part, this goes back to empowerment. But eliminating obstacles for your team is, at its most basic level, the best thing you can possibly do to ensure their success.

Obstacles can stall a project, can demoralize a team, and almost always defocus a team from the task at hand. Whether the obstacles are political (if we don’t hit this milestone, the company won’t lift it’s hiring freeze) or technical (we can’t do this work any faster unless we have faster machines to help), it’s your job to uncover the art of the possible and reduce or remove those obstacles to get the team moving at top speed.

5. Communication Over Documentation

We all know team collaboration and communication is fundamental to any project’s success, but we often live in hypocrisy by forcing our team to “communicate” through written documentation, specifications, and the like.

Documentation can be crucial. Documentation can even be a necessary deliverable for a project. But creating documents for the sake of creating documents is where many teams waste time.

After years of managing complex software development projects where volumes of documentation were produced on a monthly basis, we realized something that freed us forever:

All the architecture, requirements, design, change-order, and other such documentation was only useful as much as it a) was necessary for our customer or b) helped us reach our objective faster, cheaper, or with higher quality.

Looking back, the number of documents we created that were never opened again could fill a house. Granted, we could never have completed the project without having gone through it… but we didn’t need the document. The real value was in the meetings, the team communication, and the collaboration it took to create those documents.

If I could do those projects all over again, I would have left our team chatter on the whiteboard and gotten straight to work. 

6. Collaboration Between Business and Development

Having a technical background myself, I can attest to one thing: We engineers often forget that we’re working in a business with customers, requirements, and financial responsibilities.

It’s all too easy to focus on one problem at a time, fixing things as we go along. Each task becomes a mensa-problem, and we find intense satisfaction from solving it.

But without direction, we can veer off course, finding the next interesting problem to solve which may or may not have anything to do with the project at hand. This is where collaboration with the business side of things becomes crucial.

Business drives projects, and so having a business representative check in frequently with the project team will keep everyone aligned with the bigger picture. It will give the project team a way to prioritize features, unload unnecessary work, or ask clarifying questions about the customer requirements.

Of course, it’s just as easy for the business side of the house to add requirements as it is to remove them. So be sure everyone understands it’s a collaboration and not a dictatorship. If the project team and business team can find the right balance between driving forces and engineering challenges, you’ll be less likely to veer off course and more likely to deliver results that your customer desires.

7. Measure, Assess, Adjust

Your plan will change. It’s supposed to. As you learn and uncover new tasks, you will need to plan and replan to maintain control of the schedule (more on this later).

But if you’re not measuring, you can’t assess your progress. Worse, you can’t adjust because you won’t know when you’re starting to drift.

The best way I’ve found to measure progress is again, to not look at how much work has been completed, but to measure how much work is left. Compare that to how much time is left before your next milestone and you’ll see pretty quickly whether you were on track.

Over a period of 13 months, one of my teams and I measured both the progress and the remaining workload of our team on a month-to-month basis. We had one question in mind.

Could we quantify how much time, on average, was being spent on non-project related tasks?

We knew there are always those things that you had to do during the day that had nothing to do with the project you’re working on. Phone calls, emails, fire drills, restroom breaks. All necessary daily activities that were not being measured or track. Since our estimates on our project tasks were good, and our ability to hit our project milestones was poor, we knew that might be the culprit.

The results we saw were stunning. Upwards of 50% of our time as a team was being spent on non-project related tasks.

What we did with that information is the topic of another post. Suffice it to say, learning that gave us the ability to plan accordingly in the future. We were able to adjust the total time allocated in each milestone to better match our team’s actual project work time. Our project milestone and project release estimates became much more accurate.  

8. Create Accountability

Once you empower your team, you have to hold them accountable. If you don’t, you’re telling them their promises don’t matter. You’re telling them you don’t care about matching expectations with results.

But you do. And your team knows you do. And they expect you’ll find a way to let them know, no matter how hard.

Fortunately, it doesn’t have to be difficult. Many times, holding someone accountable is on a trivial matter... a missed email, a small slip in delivery, etc. Just reminding them why it is important to catch those emails and making those delivery dates will help them link their actions to the bigger picture.

If you’re really feeling uncomfortable about it, change your tune before approaching your team. Instead of making accusations (which only causes people to get defensive), ask simple questions. “When did you say you were going to finish that task again?” Or, “Was that a difficult email to respond to, or did you just not see it?”

Showing your team you care about their promises as it relates to the project will keep everyone honest, and maintain respect among the team members and yourself.

9. Someone Drives the Mission

The mission, the big picture, the overarching goal of the project… someone has to drive it. Someone has to remind everyone of the goal so that the smaller tasks align with it.

That person has a tremendous responsibility, usually having to do with prioritizing individual tasks.

I’m not talking about the initial prioritization. They’ll do that too, and that’s a critical step to kicking off the project on the right foot.

I’m talking about the day to day prioritization. The daily decisions that need to be made whether to work on a new feature or not, whether to solve a new problem or not, whether to delay the project or not.

In my experience, this was done by a Product Manager. But it doesn’t have to be.

In the middle of a routine project a few years back, one of our salesmen came with a frantic customer request. We were being asked to tear the team in two; one-half to continue working on the project, the other half to perform some high-priority consulting for the customer.

Despite the salesman’s best effort to take charge (i.e., derail the project himself), our product manager took responsibility for the mission and worked with our management team on the right solution for our business. She quickly calculated the opportunity cost and made a case to management that we would need to let this opportunity pass. It was only a routine project to maintain our software product, but setting us back a month would do irreparable harm to our release cycle, our current customers’ expectations, and our ability to put new features out to our market in a timely manner.

She drove the mission, and in that case, saved us from losing focus on the goal at hand.

10. Someone Drives the Execution

Execution is where the rubber meets the road. It’s where the project finds itself closer to completion, one task at a time.

Without execution, you have no project… and without someone to drive that execution, you have self-managed chaos.

Sure, teams can self-organize. Teams can set goals, break down tasks, and make progress on their own. But when everyone on the team gets into the groove, it’s easy to forget about schedules and costs. The task or problem at hand becomes the focus, and the overall project becomes background noise.

Hence the need for a driver; many times the project manager him or herself, but always someone who can perform the following duties:

1. Calculate initial availability. Take everything into account here—vacations, guestimate sick leave, company meetings, team meetings, customer meetings, travel, etc.

2. List and assign tasks. Work with the team to get everything you know on the table. Every task you can think of must be in a project plan. Estimate hours, look at task dependencies, etc.

3. Set milestones. Organize tasks into meaningful milestones that the team can reasonably hit. The more each milestone can be demonstrated to the company, the better (see below).

4. Drive the team meetings. Keep these things on track. Meet briefly, and meet often (see below). Have an agenda that aligns with the project goals and drives that agenda to completion. Oh, and drive anything that strays from that agenda straight out of the meeting.

5. Gather feedback. Feedback is crucial to learning and is necessary to eliminating reoccurring obstacles that could get in the way of future project work.

6. Bring the project to close. The final portions of nearly every project I’ve run have been intensely focused periods of time to bring the project to completion. Collaboration between the person driving the mission (from above), the project team, and the project manager are crucial.

7. Reporting. For the team, for management, and for customers. Anyone who is a stakeholder will need to understand where the project stands, so collecting and assembling the data in a meaningful report is paramount to keeping everyone on the same page.

11. The Previous 2 Can't Be the Same Person

So you’ve got someone to drive the mission and someone to drive the execution, and they are the same person?

Bad idea.

Without a healthy conflict between these two roles, either the mission or the execution will slip. To have that healthy conflict, these functions need to be owned by two separate people (split personalities are not a good idea).

At one point in my career (luckily for only a short time), I was both. I didn’t have the insight or the communication skills to challenge my manager’s decision, so I became both the VP of Engineering and Product Management.

At first, it was exciting. I had the whole project in my hands. I could help prioritize, and I could help drive tasks.

But we quickly ran into conflicts that could not be resolved by me alone. I couldn’t negotiate with myself. And I couldn’t bring myself to make the necessary schedule concessions to accommodate the technical challenges of the team.

With two separate people owning these roles, a much more productive dialogue can be had. Project complications can be met with priority adjustments. Schedule slips can be corrected with feature changes. And these negotiations can happen while keeping the mission intact, and the execution moving.

12. Plan in Detail

I had a rule on my team: If any task was larger than eight hours, we had to break it down.
We had to break it down into smaller chunks that better represented the tasks necessary to complete that job.

Example:

Write a user guide… 8 hours (NOT a good task)

Better Example:

              Write a first draft… 3 hours
              Get team review… 2 hours
              Finalize draft… 1 hour
              Publish… 1 hour
              MUCH better.

Why go through all this trouble? Because a task that is longer than a few hours tells me that the estimator hadn’t really thought through all the steps necessary to completing that task. They had defined a “mini-project” of sorts… a large to-do that had multiple smaller steps to completion.

Interestingly enough, breaking down these “mini-projects” into a series of smaller tasks helped accomplish a few important things:

It usually identified unforeseen work (read: the new total time often exceeded the original estimate).

It helped defined tasks that could be done in parallel by other team members, allowing for the work to be completed sooner.

Of course, you don’t want to get too carried away. On the flip side of an 8-hour maximum, we established a 1-hour minimum. Anything less was simply too detailed for a human being and better saved for a robot.

Whether these numbers are best for your team is for you to determine. The point here is this: You need to plan in detail… You need to plan in enough detail that an outsider could walk into your project, start working on tasks, and have a pretty good shot and completing the project.

13. Plan Often

So you have a detailed plan. Should you stick with it no matter what?

No!

The second you start work you will find it necessary to change your plan. It’s inevitable. Your team will learn new things, uncover hidden problems, and find faster/better/cheaper ways of doing things.

What you don’t want to do is wait for months, or even weeks, to take these discoveries into account. You need to incorporate them into your plan as soon as possible.

In other words, you need to plan often.

On a daily basis, as the team shares and collaborates, and learns, find a way to build these findings into your plan. Doing so will help you know where you stand daily (see above). Doing so will prevent you from realizing too late that your project schedule will slip.

14. Meet Briefly. Meet Often.

Ah, meetings… frustrating, long, boring, useless meetings. We’ve all had them. Sometimes daily.

But without meetings, how else can we discuss important issues? How else can we collaborate? How else can we avoid writing and reading emails that rival Steven King novels in size?

It’s not too hard. It just requires process and discipline.

Our method for keeping the team informed, collaborating, and moving forward was to meet daily, and to meet briefly.

For 15 minutes (max) every day, we would stand (no chairs allowed) in a meeting room with a whiteboard and the project plan. Every team member would have 1-2 minutes to cover the following topics:

1. What they accomplished since the last meeting.

2. What they are going to work on until the next meeting.

3. What obstacles are preventing them from accomplishing their work.

It was simple, it was effective, and it gave everyone the information they needed to run a successful project (and no more).

As we went around the room, other team members had the chance to chime in and offer help. Other team members could suggest solutions to clearing obstacles. Many times, other team members would chime in to say they had already completed a task that someone else was about to start… saving us valuable time that would have otherwise been wasted.

15. Share, Don't Report

When you meet often, even if brief, collaborating has a tendency to turn into reporting; only useful for the boss in the room and boring/useless for everyone else.

Avoid this at all costs (even if it means kicking the boss out of the room).

Brief, daily meetings are for sharing, not reporting. Keeping the boss informed is a nice byproduct of what should otherwise be a collaborative session to tackle project problems and move the ball down the field.

You’ll know you’re meetings have turned from sharing into reporting when you see this:

• Everyone except the person talking is staring out the window or checking email.

• The only talking done is by each person reporting or the boss (no cross dialogue between team members).

If this happens, it’s time to hit the reset button.

Remind everyone why they are there. They are there to keep everyone apprised of the current project status, prevent duplication of efforts, encourage collaboration on tasks, and help each other remove obstacles from their path.

When this happens, your team will be running like a well-oiled machine.

16. Reflect

A team that doesn’t reflect is a team that doesn’t learn.

Every so often, usually at project milestones, it’s imperative that you take a few hours to reflect. Reflect on the good and the bad. Reflect on the challenges and missed opportunities. Reflect on everything about this recent milestone so you can make the necessary adjustments to hit your next milestone easier.

Whether you meet in person for a few hours (recommended) or have everyone write their reflection down and share with the team, capturing everyone’s thoughts and ideas is critical to team growth.

Here are a few areas to consider reflecting on at the end of each milestone, and the project itself:

• Teamwork – Was it good, bad, effective, ineffective? Take care here not to call out anyone in particular. Team members will get very defensive and your meeting will quickly become unproductive if you use this meeting as a way to point the finger.

• Equipment – Was it useful or did it slow the team down? Did you have the right equipment to get the job done? Is there new equipment you could use to hit your next milestone faster or cheaper?

• Management – Yes… you should reflect on management. Did they support you? Did they get in your way? Did each team member find themselves worrying about politics, customer complaints, budget issues, etc.? Or, was the team able to focus on the project tasks and get the job done?

• Process – Did the process you used to manage the project help or hurt? How? What adjustments need to be made to make the team more efficient? Remember, the process is supposed to streamline effort, not get in the way!

• Tools – Not the same as equipment. Here we’re talking about the tools the team used to track and manage the process. Were the tools useful? Did the tools frustrate? Were they even used? What tweaks to the tools need to be made to get the team running more efficiently? What new tools could be purchased or created to do the same?

This isn’t an exhaustive list, but you get the idea. Reflecting on these few things alone will bubble up dozens of ideas that can be used for future milestones.
The important thing will be to choose a few of these ideas and actually implement them.

17. Demonstrations Mean Everything

I once heard from an investor, “An entrepreneur who can demonstrate their product instead of showing me a PowerPoint is far more likely to get my money.”

Demonstrations are powerful. They are real. They show results.

Your project is likely made up of multiple milestones. If those milestones come and go without a demonstration, you will often find (much too late) that your milestone was never really complete.

Schedule a demonstration at the end of each milestone and one at the end of your project. Doing so will focus the team on that event and all the tasks necessary to make that demo happen.

Your demonstration will be the proof that your milestone was truly achieved. It will also get everyone in the company on the same page—able to visualize the progress your team has made and get excited about the eventual outcome.

18. Keep Your Requirements Organized

Every project has its requirements. Many projects don’t know where they are stored.

Too often project requirements are in the minds of the business development, sales, and management team. If this is the case, your number one priority is to extract those requirements and organize them somewhere, clearly and publicly.

It doesn’t have to be complicated. Some of the best requirements “documents” I’ve used are simple Excel sheets listing each requirement and its priority.

The important thing is to have them documented. When they are recorded in a place everyone can access, there is no longer a question of who to go to or how to interpret them. Best of all, there is a much smaller chance that they’ll change.

19. Visualize Your Progress

Progress is tough to track, especially when you’re looking at raw data. It’s one thing to know you have 140 hours of work left in a 160-hour milestone. It’s another thing to visualize it, printed on a wall where your entire team can see.

Visualization of your project data doesn’t have to be work hours vs. work remaining (though I highly recommend doing this in addition to any other visualizations you need). You should think about what results you desire, and try to track and visualize data for those results.

In one series of software engineering projects I managed, we were having trouble with our software building correctly. The problem was, if the software didn’t build properly when everyone started work in the morning, we had to pause all further development until the problems were discovered and fixed.

The result we wanted was a “clean build” every morning, every morning.

So we had some of our electrical engineers construct a flashing light, install it on the wall, and hook it up to our software build machine. Any time the software build broke, that light started flashing and the whole team knew it immediately.

That red light helped everyone visualize the problem, and our broken builds went from a daily occurrence to weekly, then monthly, then few and far between.

Think of creative ways to visualize your project data and encourage results. When the entire team can “see” what is necessary to successfully complete the project, they will be driven to find ways to make it happen.

20. Team Size Matters

Why is it that project management seems to get exponentially more difficult as the team size increases? Because we humans are only good at tracking 7 or so things at one time.

That’s why phone numbers are 7 digits long. That’s why we have 7 or so truly close friends.

7 (plus or minus two) is that magic number of relationship we can realistically manage at any given time. So why would it be any different on a project team?

It’s not.

When you keep your project team size to between 5 and 9, you ensure good collaboration between team members, and prevent divisions that naturally occur between groups of people as they “settle into their crowd.”

Your team members won’t have to think hard about who to communicate with as problems arise. They won’t have to think hard about who to ask for help. Everyone will know everyone—their strengths, weaknesses, skills, abilities, and frustrations—and will operate much more effectively because of it.

21. Create a Tracking System

I’m not going to say much more about why a tracking system is necessary than this: If you don’t track your project (progress, risks, requirements, etc.), you really don’t have any idea whether your project will complete on time, finish under budget, or meet the quality requirements of your customer(s).

Okay, so what does a good tracking system look like? Well, it can be different from project to project. It can depend on your particular needs. It can depend on what kinds of tools your team enjoys and is effective at using.

That said, here are some minimum requirements for any tracking system you create to help manage your project:

• Easy to Use – If your system isn’t easy to use, nobody will use it. Simple as that.

• Collaborative – If your system doesn’t allow multiple team members to update it, see results, etc. it’s not going to be useful to anyone. The entire team should always be aware of where they stand.

• Real Time Updates – Your tracking system needs to show everyone results as they happen… not a day later, not even an hour late. In real time. With modern technology, there is no excuse for anyone being left behind because technology can’t keep up.

• Tracks Tasks – Teams need to see tasks, how many hours are left, who is assigned to them, etc. It doesn’t have to be complicated, it just has to be visible and easily updateable.

• Tracks Hours – See above. Tracking how many hours are left on your project vs. how many hours are left in the project is a critical metric for success. Again, this should be tracked in real time, allowing you and your team to make adjustments to meet the project goals and schedule when inevitable slips and problems arise.

• Extensible – No system you create is going to be perfect at first… so pick something that is extensible. Choose a system that allows you to tweak, add on, and change to your liking.

It’s a big list, but it’s not hard to find a system that works. I’ve used everything from sticky notes on a wall to Excel sheets to custom developed software to track projects. My current favorite is Trello, which is a bit like web-based sticky notes allowing for everything on the list above.

Find a system that works for you and never stop looking for ways to use it more efficiently!

22. Know Your Catalyst(s)

Every team has its naysayers; those people that err on the side of caution… who maybe see the world as glass-half-empty.

These team members are necessary. They keep us grounded. They prevent rash decisions.

But there comes a time in any decision-making process where the thinking and debating and caution needs to make way for a final verdict. And when that final verdict comes, you need everyone on board for maximum results.

This is where your catalysts come in.

Catalysts are those team members who get behind your decision, promote it with the team, and get other team members on board. They are the respected ones—the team members who have a history of good decisions and successful projects in your company.

That catalyst may have been you at one point. You may have been the person to rally the troops, break down barriers, and get things going. After all, that’s why you’re running projects now instead of working on them.

But that catalyst can’t be you anymore. When you have authority, even if only over a single project, your team will only debate with you so far before they decide it’s better to keep their mouth shut and show support. But if they’re not completely on board, they’ll only show support when you are in the room.

So you need to find new catalysts on your team to carry the torch for you. When big decisions come up, get them on board first. Ask their opinion, get their feedback, and make them a part of your decision-making process.

When they have been a part of it all, you will find them rooting for you in team meetings and behind the scenes. The naysayers’ barriers will crumble and you’ll be left with a unified team who gets behind you and goes to work.

23. Individuals, Not Teams, Own Tasks

If you’ve ever heard the phrase, “everyone’s problem is no one’s problem,” you know exactly why a single person needs to own a task.

That’s one person, not two, not four. Not “me full time and a bit of him here and there.” One person owns a task. One.

Did I make my point? I hope so, because though many problems are significant enough to warrant multiple people’s involvement, there should still only be one owner.

Without a single owner, it’s too easy to point the finger when that task gets stalled. Without a single owner, it’s too easy for everyone to wait for everyone else to step up and make something happen.

In other words, there’s no accountability.

On the flip side, when a single person is assigned or takes responsibility for a task, they understand it’s theirs to finish. And, if they are empowered (see above), they will take appropriate risks and take appropriate action to get things done.

24. What to Do or How to Do It

When I first started managing projects, I knew I knew it all. I knew what to do, when it needed to be done, why we were doing it, and the most effective way to do things.

Okay, okay, so I still feel that way today. But I’ve learned to filter myself, trust my team, empower them, make them accountable, and let them fail, grow, and succeed on their own.

When I did that, I discovered two important things:

Your team will surprise you with their creativity and effectiveness.
You will have more time to spend focusing on the big picture, the process, and removing impediments from your team.

I’ve always loved the saying, “you can tell me what to do or how to do it, but not both.” Anything else, in my humble opinion, is micromanagement.

25. Control Change

Changes in a project are inevitable. New requirements are going to pop up. Maybe you missed them early on, maybe some new technology or opportunity has emerged, or perhaps a customer is asking for more. 

Some proposed changes are going to be good ideas and some are going to be bad. Regardless, all changes have one thing in common once you’ve started a project – they will have an impact on the schedule and cost of the project. 

And the further along the project is, the greater the impact will be. 

A strong project manager will seek to minimize all unnecessary changes for the sake of getting the project delivered. That doesn’t mean ignoring change requests is a good idea – you should have a system to capture and prioritize them for evaluation and future consideration. 

If you come across a change that must be addressed, make sure to take into account and communicate the implications for your timeline and costs. 

Bringing It All Together

This is a huge article, full of lessons that couldn’t possibly be incorporated in a single sitting. Don’t worry, it is meant to be something you can draw on in the months and years to come.

Whatever you do, start now. Whether you are about to begin a project, or in the middle of one, choose one of the lessons above and design a plan change your project management for the better. Of course, we’re here to help. If you need assistance creating a plan, or just reviewing yours and providing feedback, contact us at info@moderndavinci.net.

About the Author

Michael Mehlberg

CO-FOUNDER | TECHNOLOGY, PRODUCT DEVELOPMENT, MARKETING, AND SALES

Michael Mehlberg helps small businesses owners achieve their goals and live their passion. His approach to technology, corporate strategy, product development, marketing, and sales is both practical and highly effective, and has helped multiple small businesses grow into the company their owners envisioned. Reach out by emailing him at mike@moderndavinci.net or learn more on our About page.