Mar 10, 2016
Have you ever been asked to lead a project? As the excitement of your newly-acquired responsibility subsides, it is slowly replaced with the sinking feeling that you have almost no idea where to even begin or how to go about setting up a project management process.
Does this sound familiar?
Over the course of my career, I’ve picked up a few hard-won lessons on project tracking, collaborative project management, and online project planning.
These lessons certainly came in useful during this past year when I was asked to take on the project management responsibility for redesigning the TeamViewer website.
I’d like to share some of these lessons with you, so that you might benefit the next time you’re asked to manage a project.
It’s probably not too far from the truth to say that we have all likely felt a bit overwhelmed in our professional lives when confronted with challenges that are outside our comfort zones.
How we approach such challenges shows our willingness to take risks, learn from mistakes, and, ultimately, expand our knowledge and capabilities.
Having the courage to face these challenges is one of the most rewarding aspects of a successful career, in any profession.
When projects are complex, involve a lot of different resources, and require many different areas of expertise, project management becomes an essential element to achieving success.
Project management is an entire profession with its own tools, numerous methodologies, certifications, and dedicated professionals, and there are many approaches to project management.
However, this article is not intended for the professionals.
This article is actually for all those people who have been handed a big project that goes beyond their usual responsibilities and told to run with it.
That being said, any tips or feedback from any project management professionals would be very welcome here.
The very first lesson is not to panic. Approach the entire project like a NASA engineer or astronaut. Concentrate on the task at hand and simply work the problem.
Take a deep breath and then start with the big picture. Don’t let yourself get caught up in minor details. Those will become evident in due course.
When tackling the website project, it would have been all too easy to immediately start thinking about new images, wording, new pages, or any number of other elements.
This would have only caused problems, slowed momentum, and proven fruitless.
You don’t have to figure it out all at once. You develop a plan and adjust it as needed.
Keep in mind that the plan you define will not be set in stone. It is your overall guide. A plan that cannot be modified isn’t a very good plan.
Before you can create a plan, you need to know what you want to accomplish.
You must define your overall goal. Now stop and look at that goal and really define it. It can, and should:
Don’t make it open ended. That’s not a goal; it’s a wish.
That NASA engineer’s goal is not “to go to Mars.” Instead it’s “to send a manned mission to Mars with a crew of 4 to conduct soil and atmospheric research and to launch the mission within 5 years.”
Even that’s a pretty broad goal, but you’re already starting to form a picture of what is really required to make it happen.
A well-defined goal makes it possible to immediately see some basic requirements, milestones, and necessary dependencies (i.e. you can’t start part Y until X is complete).
Our goal couldn’t have been to simply build a new website. Why would we have done that? We already had a website.
Instead, the goal was defined to include:
Actually, the goal was even more detailed than that, but you get the idea.
The detailed definition of our goals was invaluable throughout the entire project.
Many necessary steps for the website project became readily evident once the goals were defined.
Based on customer feedback, after sales surveys, and analytics, we formed a picture of who needed to use the website and how.
Not to get too into the details, but this helped us define exactly what information we needed to present on the website, and in which order.
From there, the user interface and user experience could be formulated. Only then was it finally time to talk about design and specific content.
Analysis also revealed to us that a surprisingly large number of people still visit our site using Internet Explorer 8. That helped clarify some additional details.
Right away, we knew that certain optimizations were going to be necessary.
Some whizzbang web features available to the most recent browsers were not going to be options for us unless we were willing to drop support for some older web browsers.
As you develop your plan, you will quickly notice that there are often very few right or wrong answers.
It’s frequently a compromise in the sense that something can be done this way or that way, but always at a cost.
Match your plan to your overall goal and constantly refer back to that goal. If the plan starts to deviate from achieving the goal, you alter the plan.
Don’t forget though that, armed with ever greater knowledge over the course of the project, it might occasionally be better to adjust the goal, and this doesn’t always mean downward.
Sometimes you realize that even more is possible than you initially thought. Be ambitious.
Well-defined goals help to determine necessary requirements, major phases, and milestones, but there are some other aspects of managing a project that are critically important.
In my experience, two of these factors are estimating the time to complete specific tasks and information management. Let’s talk about time first.
First of all, it is essential to estimate the time it is going to take for the specific tasks or phases of a project. Those are your goals (not wishes) within the overall goal of the project.
If you haven’t set deadlines, don’t be surprised when nothing gets done.
It also helps, a lot, to work backwards.
For the website project, that meant saying, “OK, if this thing needs to go live at the end of 2015 and we need at least two months just to code the site, the design has to be complete by the end of October”.
This in turn meant that the wireframe mockups needed to be provided to the designer in September, and so forth.
Recall however, that I mentioned that plans need to be flexible.
Asking a software developer how long it’s going to take to fix a bug is a silly question. Most likely they’ll say, “Well, until I know what’s wrong, I have no idea.”
A really experienced developer might say, “two weeks,” but that’s just to get the project manager to stop bothering him, and an experienced project manager (PM) won’t ask.
Instead, the PM will say, “let me know when you’ve identified the problem and then we can talk about out a solution and how long it will take to implement”.
When such an issue occurs, it’s actually the responsibility of the project manager to determine how critical that issue is to the overall project.
If the issue is along the critical path (the absolutely essential steps), it will almost certainly cause a delay.
If not, see what resources are available to handle it, and let it run in parallel with the rest of the project.
So now that I’ve spent all this time talking about the importance of setting deadlines, I’m going to say something that sounds contradictory. Every single little subtask doesn’t need a deadline.
If you’ve ever dabbled with any project management software solutions, you’ll likely have come across blank fields for start and end dates staring back at you, just begging to be filled in.
It is very tempting to succumb to the pressure to fill in these areas with invented numbers in order to generate pretty reports; however these reports are not reliable. As the saying goes, garbage in equals garbage out.
The alternative is to spend inordinate amounts of energy chasing people down to get realistic estimates for every little task, and the numbers might still not be reliable.
To resolve this, keep the tasks high-level enough that the deadlines serve a genuine purpose and have real meaning.
Trust the people assigned different tasks to know what subtasks they need to perform. In fact, they likely know much better than you do.
Referring back to the TeamViewer website for instance, it was more than enough for me to know that the development team was working on the proper server setup and was going to have it ready for testing by day X.
The various subtasks related to that were irrelevant for me. I likely wouldn’t have understood a lot of it anyway.
As the saying goes, if all you have is a hammer, then every problem looks like a nail.
Project management software is wonderful, especially if you know how to use it.
There are various solutions out there, each with varying degrees of complexity.
But the good news is you can also just use a spreadsheet or even a word file.
The key is to make sure that you have the right tools for the project you’re working on, for your style of working, and for your level of experience with such tools.
Don’t shy away from learning how to use some new tools, but also don’t force yourself to use something that just isn’t working for you. Rather than waste the time, look for an alternative.
Use an appropriate mix of tools. Don’t just hit everything with your hammer.
To relaunch the TeamViewer website, the team regularly relied upon a variety of tools.
Of course, I routinely used TeamViewer for group meetings between departments and with suppliers involved in the project.
Screen sharing made it possible to look at designs and mockups together to discuss changes or explain concepts.
I sent chat messages to the development team to ask short questions or make quick requests. This was excellent for avoiding cluttering up somebody’s inbox with emails saying, “Hey, can you put the latest version up on the test server before lunch?”
I also went through an awful lot of Post It notes for quick little to-do lists, reminders of questions to ask in the next stand-up meeting, etc.
The most important thing I found is to stay flexible. Focus on managing the information and making sure that everyone is on the same page and pulling in the same direction.
Technology often assists in this, but don’t let it dictate how you do things. You determine the processes and use the software to support your efforts, but keep an open mind for new ways of doing things.
I hope you’ve found these insights useful, and I would be glad to receive any of your suggestions in the comments section below.
Here is a summary of key takeaways to make your next big project a success: