144 Comments
Requirements are the lifeblood of projects. That’s one of my mottos anyway. If you don’t have a list of what needs to be completed, how do you know what to accomplish, or even when the project is actually finished? This is why requirements are critical to a project’s successful outcome. A project that is started without good, complete requirements in place is definitely in trouble from the beginning.
Continue reading “Good Requirements and the Successful Project”
Are you a Project Manager that wants a different look for your schedule’s bar styles, but you don’t have the time to play around with different designs for your bar styles? Or maybe you just lack artistic mojo, yet would like to use bar styles not in the program’s drop-down selection?
We understand, that’s why we’ve provided a Template/Example Schedule within FastTrack Schedule 10 that contains 200 additional bar styles for you to choose from and incorporate into your schedules.
Continue reading “Get and Use 200 More Free Bar Styles”
This Topic was Recently Updated.
When we are building projects, two of the most important types of data that we need to keep track of are budgeted and actual cost values.
To display a project’s task costs, use the Cost Layout. This will display cost information for Fixed Cost, Resource Cost, and Total Cost.
Notice that in the Cost Layout there is no column for Budget values. We can easily create this on our own.
Continue reading “Using Calculations to Find Cost Variance”
Project Managers are organized in everything they do, right? Well, I can say that I’m not.
And when I was attempting to change a tire on our full-sized 12 passenger van… I learned that I’m even less organized than I thought. My little kids were helping… so at least that aspect was fun.
The worst part? Everything else. I hate redoing work more than just about anything else. And I’ve been an application developer and a project manager long enough to know that rework usually comes from poor or incomplete planning/communication. I try to avoid both, but in the case of my flat tire, I failed.
What should have taken me 30+ minutes with some advanced oversight and planning, took me about four hours and a lot of unnecessary pain, sweat, and aggravation.
Why? Because…
Continue reading “How Changing a Flat Tire Made Me a Better Project Manager”
This may seem like a simple question, but the answer is bigger than we think it is. We’ve all grown somewhat immune to the mocking of those in charge – you see the President of the United States and other world leaders mocked on TV and other media all the time. But really, what about the leadership of your company? Do you have confidence in them? Do you think they have your back? Do you feel like they’re leading you, your co-workers … even your customers in the right direction?
I think the answer for many of us is often ‘no.’ And that’s sad. Why is that … why do we feel this way?
Continue reading “Is Your Boss Trustworthy?”
Sometimes what you’re really trying to solve is a bit hidden. The customer may not see it and you might not at first glance either. But it is your responsibility to make sure you always go that extra mile to make sure you are addressing the real issue and not just a symptom that the project sponsor sees and what seems obvious to everyone.
Sometimes there is more to a problem than what you can easily see.
It’s not always easy to truly identify what is the real project. On the surface, it seems obvious. The customer comes to you with ‘x’ need and you work with the customer on business processes and requirements and move forward with work on a solution for that customer. You have a project involves working to solve the customer’s identified need.
However, it’s not always that easy … and as the Project Manager, you must assume that the customer doesn’t always know what it is they want or even what their true need is. Identify that true need, and you’ll be building a solution that keeps the customer happy.
Problems and opportunities can arise almost anywhere inside or outside the organization. Problems are typically driven from within and frequently relate to improving organizational performance. For example:
| Problem | Solution |
| A department that’s overwhelmed with paperwork. | Simplify procedures. |
| An organization that constantly faces the prospect of worker strikes. | Improve management/employee relations. |
| An insurance company that has branch locations spread across a wide geographic region. | Communicate effectively among branches. |
Problems are generally regarded as negative. Opportunities may be viewed as their positive alter ego.
Opportunities are often driven by external forces. More common examples can be found in the areas of product development or product enhancement. These opportunities are often the response to a perceived need in the marketplace. In other words, sometimes a problem leads to opportunities.
The term “true need” refers to the most basic problem to be solved. Identifying your project’s true need can, at times, be tricky. But it’s absolutely vital that you as the Project Manager understand what the true need is.
Why? Because many will judge you as a project manager by your ability to solve the original problem. Solving the original problem equates to satisfying the true need and you and your project team often have to dig to find out what that true need actually is. You cannot be certain that you’ll satisfy the true need unless you know what it is. The problem is that when you’re assigned to manage a project you may not be presented with the true need explicitly. Terminology can become confused: what’s described as a need may actually be the solution to a need.
One of the most reliable methods for uncovering the true need is to ask the right people one simple question: “Why?” However, as you seek to uncover the true need, you can expect to encounter some resistance.
If you ask questions rather than digging in and getting the project going, some within your organization may assume that you’re not moving forward. However, asking the right questions of the right people can often lead to some startling discoveries.
Readers – have you had many projects where the real need was buried and the customer was actually coming to you with a symptom? I have … and the end result would have been disastrous if my team and I had only delivered on the symptom rather than digging for the real problem. Please share your experiences.
In Part 1 of this two-part series on figuring out whether or not what we have viable project … we looked at what brings us to the go / no-go decision point and how we review a project from both a justification standpoint and a feasibility standpoint.
Now, in Part 2, we’ll consider how to:
Once you fully understand the project’s goal and establish that it is justifiable and feasible, you’re ready to determine the best way to satisfy that need. (You may wish to review Part 1 of this series.)
Although I’m using the term “you,” proper execution of this step really requires the input of many individuals. If you’re fortunate enough to be involved at this stage of the project’s evolution, you should be actively working toward building a team that can work with you from this point on.
The process of identifying the optimal way to satisfy the project requirements begins with generating a list of potential solutions. This process is made easier when these elements are included:
Obviously, you can’t pursue every idea identified through processes like brainstorming.
After soliciting all reasonable alternative solutions, the project team needs to pare the list down to only those that are worthy of further development, investigation, and definition.
You can reduce the list by comparing each alternative against predetermined criteria. This is where the Requirements Document begins to add significant value. The process for selecting the optimum solution begins by evaluating each alternative solution in terms of how well it satisfies the most critical aspects of the project requirements, such as budget constraints or strategic alignment.
You may also wish to use other requirements-based considerations, such as the likelihood of technical success or the anticipated impact on existing products. This initial screening will allow you to shorten the list of potential alternative solutions to a manageable number (I would recommend two to five).
At this point, the selection process becomes much more rigorous. Each potential alternative should be evaluated using two basic types of criteria: financial and non-financial.
Readers – how do you feel about this process? How does it match up with your organization? Do you have similar processes you can share and discuss?
Not every project is cut and dried and definitely a project – some have to be fleshed out and decided upon … is this really something we should be doing and is this the best way? If not … what is? Please share your thoughts.
In one of my past lives in corporate America, I worked at a very large, Fortune 500 engineering and aviation firm that featured a central Project Management Office (PMO). There existed a requirement for all project managers to go through the following exercise on the larger projects (not all of the smaller projects required a formal process like this):
Two things to understand first before going any further:
The sole purpose of the Tech Council and the PM presentations was to ensure that the project was worthwhile taking on (since everything was internal and really represented a shifting of money from one department to another rather than actual income – except where costs were being saved) and to ensure that legacy technology was not going to be used in a long-term solution when that technology was planning to be phased out and unsupported in the near future.
So, in a sense, the Tech Council was basically a go – no-go decision point early in the project. Even though it was early in the project it was a good time to ask:
Buried in these four questions is addressing the issues of justification and feasibility. You should deal with both issues before continuing no matter what customer base you’re servicing – internal or external. If not, you run the risk of wasting time and money on problems that should not or cannot be solved.
Particularly financial justification—is very difficult to assess at the requirements stage, because not much is really known about the project. Nonetheless, it’s wise to try to assess whether or not you can justify continuing the project. You may be able to do this by executing a simple cost vs. benefit analysis.
The benefit component is relatively easy to estimate: it’s the value of satisfying the need. In many cases, this is nothing more than calculating how much the problem is costing today. Estimating the cost of the solution is more difficult, because you’re not sure what you’re going to do or how you’re going to do it. One approach you may wish to consider consists of working backwards through the financial calculations. By doing this, you can determine the most you’d be able to spend on a solution. If none of your proposed solutions can be executed for less than that amount of money, the project will ultimately be unjustifiable—at least from a purely financial standpoint.
This comes down to a basic question: Do you believe that a solution exists? In other words, can this problem even be solved? This step is referred to as verifying feasibility. There can be much subjectivity in this step; you should rely heavily on the judgment of subject matter experts (SMEs). In reality, the most that you can realistically hope to determine at this point is that the possibility of a solution is thought to exist. That’s OK. As with justification, all you’re trying to do at this point is preclude the expenditure of additional resources and money on problems that have no reasonable solution.
This step is referred to as verifying feasibility. There can be much subjectivity in this step; you should rely heavily on the judgment of subject matter experts (SMEs). In reality, the most that you can realistically hope to determine at this point is that the possibility of a solution is thought to exist. That’s OK. As with justification, all you’re trying to do at this point is preclude the expenditure of additional resources and money on problems that have no reasonable solution.
In reality, the most that you can realistically hope to determine at this point is that the possibility of a solution is thought to exist. That’s OK. As with justification, all you’re trying to do at this point is preclude the expenditure of additional resources and money on problems that have no reasonable solution.
In Part 2 of this two-part series, we will look at working to identify the best solution possible for the project need and whether it is feasible to proceed with the effort.
Readers – please be thinking about your own processes that you and your team or management go through to make project go / no-go decisions and be prepared to comment and discuss.
Schedules are living documents, so oftentimes we need to review them regularly to look at what has been done so far and make changes to what still needs to happen. One of the easiest ways to do this is to hold reoccurring weekly meetings.
FastTrack Schedule makes it easy to pick each specific date and time that our recurring tasks will happen, we can even create dependencies to and from these meetings to show how they interact with the other portions of our project.
For today’s example, we will build a recurring task to represent our weekly status meetings. When we enter our task, we will create a zero-day duration to mark it as a milestone within our project.
Once we’ve created numerous meeting instances, you will notice that each milestone on the Timeline Graph will line up directly with its corresponding date in the Start/Finish Date column. If you prefer, we can change this behavior so all bars appear on the same, centered line.
This will align all of your milestones to the grid of the row, which by default matches the alignment of the row number.
We can also create dependencies between our tasks to show a realistic flow from meeting to meeting, and any steps that may occur in between.
Have you ever had a project where you needed to show recurring tasks, but entering each of them into a new row was too cumbersome and clustered to view? In your upcoming projects what are some ways you can make use of recurring tasks to better show the flow of tasks?
A reader of one of my articles recently commented about people blaming others for failures on projects and workplace tasks. We all know he’s right … some of us may have been guilty of it ourselves once or twice … or had the finger pointed at us in the ugly blame game. But that isn’t very professional and it still won’t resolve the issues with the failed or failing project – something still needs to be done no matter who’s fault it is. Let’s look at the whole blame scenario and how we might react and resolve the situation.
The reader states that some PMs have a tendency to blame everyone and everything else when things go wrong. He says that all too often he see PMs blame others (suppliers, team members, customers) or things outside of the project (like the economy or the weather or even the exchange rate).
He’s right. There are people in organizations – not just PMs – that do this all the time. And there are PMs – the ones in leadership positions on projects – who are pointing the finger constantly at team members and customers, often just to make sure that they still look good when it hits the fan.
Continuing on, the reader states in his comment that a good PM looks in the mirror first and should be the first to admit the mistake. I agree completely, though admitting mistakes is very hard for some. As the PM, we’re in charge and everyone is looking to us for our leadership. The PM must be in charge and must be ready to take charge and certainly must be ready to take responsibility for things that happen on the project.
I’m not stating that a PM should take blanket responsibility for every bad thing that happens during an engagement. Not at all. Rather an approach of ‘let’s see what we can do to get through this issue together’ is a good course when the problem was obviously caused by something beyond the PM’s control. The PM should not be a martyr taking on all blame no matter who was responsible. Nobody really likes a martyr who takes the weight of everything on their shoulders, but nobody in their right mind is going to follow a PM who finger points when issues arise. No good comes from it and no problems are really solved by it … all it serves is to divide the team and that is a recipe for disaster.
First, personally, don’t become one. Have you ever found yourself easily pointing the finger at someone else – even privately among your team members? I have, and I hate myself for it later. It can also be detrimental to your leadership position with your team members – if they see you as a finger-pointer in the blame game, then they will not be seeing you as the take-charge leader you need to be.
How should we deal with this type of behavior when project problems or failures arise? Here are my first thoughts…
If the private discussion doesn’t have the needed effect on the team member, then take it to their manager and ask that they be reassigned and replaced on the team. Stop the cancer before it spreads to the rest of the team.
Project managers and project team members … have you seen this in your workplace? I’m sure you have at some point. Was it on your project? How did you deal with it? How would you deal with it? Please share your own experiences and let’s discuss.
