177 Comments

Get and Use 200 More Free Bar Styles

06/13/2017 by Jackie Dembinsky Tags: , ,

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?

Free - 200 More Bar Styles

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”

177 Comments
237 Comments

Using Calculations to Find Cost Variance

06/06/2017 by Jackie Dembinsky Tags: , , , ,

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.

In FastTrack Schedule 10:

  • Use the Cost Layout to input a budget and automatically calculate actual costs.
  • Create calculations to pinpoint tasks that are over budget within our projects.Identify the amount a task is over budget.
  • Make a column automatically display whether a task is over budget.
  • Make a label automatically appear on an activity bar to make a over-budget task more noticeable in the Timeline Graph.

Use the Cost Layout to input a budget and automatically calculate actual costs.

To display a project’s task costs, use the Cost Layout. This will display cost information for Fixed Cost, Resource Cost, and Total Cost.

  • Fixed Cost is any cost not directly relating to our resources.
  • Resource Cost is calculated based on the resources assigned cost rates and the number of hours they are assigned to tasks.
  • Total Cost is the combination of Fixed Cost and Resource Cost.

Notice that in the Cost Layout there is no column for Budget values. We can easily create this on our own.

Cost Layout

  Continue reading “Using Calculations to Find Cost Variance”

237 Comments
132 Comments

How Changing a Flat Tire Made Me a Better Project Manager

04/14/2017 by Brad Egeland Tags: , ,

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”

132 Comments
76 Comments

Is Your Boss Trustworthy?

03/23/2017 by Brad Egeland Tags: , ,

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?

Trust button set on highest position. Concept image for illustration of high confidence level trusted service or review.

Continue reading “Is Your Boss Trustworthy?”

76 Comments
144 Comments

Do you know what the REAL project is?

03/09/2017 by Brad Egeland Tags: , , , ,

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.

Unknown opportunity concept as three dimensional text hidden underwater with a viral healthy tree growing on a small piece above water as a metaphor for success and motivation to search for hidden opportunities in business and life.

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.

Get the big picture by asking the right questions

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.

Identify the true project

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.

Summary / Call for Input

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.

144 Comments
25 Comments

Is the Project Worth Saving? (Part 2 of 2)

02/23/2017 by Brad Egeland Tags: , , , ,

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:

  • Review alternative solutions for your project’s problem(s)
  • Identify the best solution for moving forward

Project Justification and Feasibility.

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.

Identify Alternative Solutions.

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:

  • Do it in a team environment
  • Include subject matter experts and stakeholders as appropriate
  • Use brainstorming techniques
  • Limit further development to only reasonable alternatives

Choose the best solution for moving forward.

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.

It takes a team to develop solutions and reach goals.

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.

Summary / Call for Input

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.

25 Comments
79 Comments

Is the Project Worth Saving? (Part 1 of 2)

02/16/2017 by Brad Egeland Tags: , ,

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):

  • Kickoff the project with the customer
  • Document high-level requirements with the customer
  • Ballpark a solution and an estimate
  • Perform a formal project presentation to a technology council

Two things to understand first before going any further:

  • Nearly all projects at this company for the Project Managers (PM) were internal
  • The Tech Council was made up of internal executives

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:

  • Is this problem worth solving?
  • Does a potential solution exist?
  • Are we going about this solution in the right way?
  • Does this fall in line with our overall company goals and mission?

Justification and Feasibility

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.

Woman says that she dreamed the answers to their problems.

Justification.

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.

Feasibility.

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.

Summary / Call for Input

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.

79 Comments
168 Comments

Creating Recurring Tasks within a Project

02/05/2017 by Jackie Dembinsky Tags: , ,

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.

Create Recurring Tasks

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.

  1. Input the Activity Name and initial Start/Finish Date for your initial meeting.Zero Day Duration
  2. Add a new row for your next meeting date:
    • Place your cursor after the Start Date (11/15/12) for our “Status Meeting” task
      – Windows Users. Hold down Alt and press Enter.
      – Mac Users.       Hold down alt/option and press Return.
      This will create a new line for data within the current row.
  3. In this new row, we can select the next specific starting date, whether it is on the same day of the week or a different day completely, for our Status Meeting.New Row within the Row
  4. You can repeat the above process as many times as necessary to show each occurrence of this Status Meeting during the duration of your project.Multiple rows within the row

Change Vertical Alignment of Recurring Task Milestones

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.

  • Windows Users. Right-click or Control-click any milestone and choose Select All.
  • Mac Users. Right-click or Control-click a selected milestone and choose Align to Grid.

This will align all of your milestones to the grid of the row, which by default matches the alignment of the row number.

Row within row vertical alignment

Create Task Dependancies

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.

Milestones have task dependancies

Contribute to the Conversation

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?

168 Comments
151 Comments

Handling the Blame Game

02/02/2017 by Brad Egeland Tags: , , , ,

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.

Finding someone to blame the bad stuff on.

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).

Finger-pointing, placing blame on someone else.
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.

Look in the mirror.

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.

How do you deal with this type of leader?

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…

  • Re-direct the discussion from finger-pointing to aggressive resolution (if you’re not part of the solution, you’re part of the problem).
  • Have an offline conversation with the offending individual about the negative aspects of that type of behavior and its effect on the rest of the team.

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.

Call for input

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.

151 Comments
77 Comments

PM Oversight of the Project Delivery Team

01/26/2017 by Brad Egeland Tags: , , , , , ,

One key aspect of the responsibilities of the Project Manager (PM), of course, is his or her management of the project delivery team. This is where the real work happens, where the rubber meets the road and how the project moves productively forward. It is a lot of responsibility and takes some obvious skills and planning to do it right… beginning with getting the resources planned, through project kickoff, and on to the actual performance on the project.  Let’s discuss…

Business team of success pop art retro style. The joint work. Business success. The schedule of growth. the business staff. Firm

Good oversight leads to a team that works together and is successful.

Resource Assignments

Let’s assume the team is assembled by leadership within your organization. I’ve been in organizations where one person managed the PM Office and assigned PMs to projects based on availability, geographic location, and expertise, and another person managed the Business Analysts (BA) and made assignments to projects based on those same considerations.

The technical staff is usually managed by a Development Manager or CIO (or both) and the technical resource assignments are made based on availability and expertise and they are often not full project timeline assignments like the PM and the BA positions. Those technical resources are assigned as needed and as determined by the project schedule and resource forecast maintained by the Project Manager.

Kickoff

Prior to the Kickoff of the project, the PM distributes all relevant project and contract information to all assigned delivery team members. This would usually include, at a minimum:

  • Statement of Work (SOW)
  • Original resource hours forecast/budget as finalized by Sales
  • Initial project schedule as created by Sales for the customer
  • Contact information for project team members on both sides
  • Any relevant travel and expense requirements as mandated by the customer

In addition, the Project Manager and the Business Analyst are preparing heavily for the Kickoff Meeting with the customer and planning for the move into Exploration. Frequent, ad-hoc communication is happening at this point to coordinate efforts and ensure that both are on the same page.

Onboarding

Once Kickoff is over, technical resources will begin being assigned (as needed) to the project and the effort of managing the delivery team resources and forecasting for their usage becomes a more important task for the Project Manager.

As new resources are engaged on the delivery team side, four things must always happen…

  • Provide the relevant project/contract docs for review
  • Provide recent status reports and the project schedule for review
  • Provide the resource forecast for review
  • Hold a formal delivery team meeting to go over current status, key project info, and answer questions

Ongoing oversight of project tasks

Once the project is fully staffed and is moving from Exploration to Design and beyond, then the effort of overseeing the work of the delivery team members should be fairly straightforward. Maintaining proper communication and the structure that should already be set in place will help ensure that each team member is up-to-speed at any given time on project status and what is expected of them at that moment and for the upcoming weeks. Just to review, this proper communication/structure should be in the form of:

  • Weekly delivery team meetings
  • Ad-hoc delivery team communication
  • Weekly formal status meetings with the customer
  • Weekly delivery of and review of the revised project schedule
  • Weekly delivery of and review of the project resource/budget expenses and forecast

Summary & Call for Comments

If all of these items are well maintained and delivered to team members in a timely fashion, then everyone will be on the same page. The Project Manager must be well organized because usually the PM is dealing with delivery team members who have other projects to work on that are in various stages of implementation.

Your delivery team members must always be made aware that this project is critical and that you have a solid structure in place or you’ll lose them to other activities and you’ll have more difficulty re-directing their efforts back to your project tasks. It’s much easier to lose resources to their other critical activities on other projects than it is to reign them back in … so stay organized and fight to not lose their focus in the first place.

Readers – how does this match up with your experience and expectations? Please share and discuss any additional information you care to add. Thanks!

77 Comments
« PreviousNext »