Lonnie Pacelli's Blog, page 56

Trying New Things Isn't Very Fun-One Minute Lessons on Raising Autistic Kids

Even Fun Surprises Can Wreak Havoc-One Minute Lessons on Raising Autistic Kids

The Sound of Business Podcast - Pacelli Publishing

My friend and colleague Chris Carlson from The Sound of Business recently interviewed me about our publishing business Pacelli Publishing.  Really fun to do and hopefully provides a couple of nuggets for someone looking to publish a book.  Audio link below; hope you find it helpful

They Need to Keep a Schedule-One Minute Lessons on Raising Autistic Kids

Tips to Teach your Kids about Money

I recently did an interview about tips to use when teaching your kids about money.  In thinking through some techniques, I was able to lock on some specific things we did which helped to better instill good money management habits in our kids.  Here they are:

1.  When our daughter was in her tweens, we started working with her about purchasing decisions and saving up for things she wanted. Here’s what we did:
 We increased the amount of her allowance, gave it to her quarterly, but then had her use her budget to buy all of her own clothes and other personal items

- We kept track of inflows and outflows on an excel spreadsheet

- If she wanted something we would ask her if that was where she wanted to spend her budget.  If she said yes then she made the purchase but then she had to wait until she had enough money in her account to buy other things

- Right after we put this into effect, she and my wife were in Nordstrom and our daughter saw a pair of flip-flops she wanted.  She asked my wife if she could get them.  My wife responded, “Is that where you want to spend your money?”  She ended up buying flip-flops at Target.

2.  Both our kids got checking accounts before age 16 and credit cards at age 18.  The rationale for doing is that we wanted to make sure they learned about the concept of interest and making payments versus paying their bill in full every month.  We wanted them to learn good habits while at home as opposed to learning bad habits while at college.  While discussing with our daughter, she asked the question, “You mean if I don’t pay it off in full every month then I’m paying interest to the bank and getting nothing in return?”  After I told her that was exactly the case she vowed that she would always monitor her spending so she could pay her bill in full every month. Both our kids are experienced with credit cards and neither has paid a dime in interest charges because they couldn’t pay their bill in full every month.

3.  Our eldest is out of college and youngest is still in college.  When our eldest got her first job as a nurse we had a deliberate discussion about her saving for retirement.  She contributes the maximum amount to her 401k, has saved up enough for six-months of living expenses, and lives off the rest.  She drives a ten-year-old car because it’s “good enough”.  She still indulges in the nice purse or a weekend away, but does so within her means.

4.  Most of the discussion has been about our daughter, but we did the same things with our son.  He and his big sister are better disciplined money managers than many adults I know.  Oh and our son is also mainstream autistic and still is able to manage his finances like a hawk.

Defining a Meaningful Workplan in Microsoft Project

So okay, Microsoft Project is a super flexible tool in helping you as a project manager define your project tasks, dependencies, and resources.  Quite frankly, though, the workplan you define in MS Project is only as good as the thought that goes into it.  Too often I've seen savvy MS Project users completely bungle a project because, while the tool was being used appropriately, the workplan didn't make sense to the project team and didn't reflect what really needed to be done.  The team consistently expressed confusion about what needed to be done by when because the project workplan wasn't reflective of the actual work which needed to be done.  Great exercise in using MS Project, but poor execution of the project.  Blech.
As project managers, we need to ensure that a project workplan succinctly satisfies the goal of the project, accurately reflects the work to be performed on the project, and is last but not least easily understood
by the project team.  Through the years I've blown a number of projects because I failed to succinctly and clearly define the work appropriately in a way that the rest of the team clearly knew what needed to be done.  As I look back on my failures I can point to several factors which led to a fuzzy workplan, as follows:
Unclear project objective - The team was not in unison about the objective of the project and what "done" looked like.

Poor task groupings - Tasks were grouped illogically to where each grouping didn't represent a project deliverable or easily definable milestone.  
Stale tasks - Tasks in the workplan did not accurately reflect the current work to be performed.  As things changed on the project the workplan didn't keep up with the changes.  

Maintaining the project workplan became the focus of the project - Rather than focusing on the end deliverable, focus was  more on defining the "perfect project" in MS Project.  All the features of MS Project were exquisitely used, but the project imploded nonetheless.

As project managers, we all need to ensure that the workplan is a tool we control, not something that controls us.  Many younger project managers seek comfort in tools and make the assumption that  if the tool
is used properly then the project will succeed.  Avoid this  mistake by taking the following steps:

Ensure the project objective is easily articulated and understood by the entire project team - Physically write out the project objective and what success looks like for the project.  Ensure the team understands the project objective and has no question as to the success criteria.  Unless you've got clarity on the objective don't bother going further; you'll just be wasting your time.

Work backwards - Starting with your end deliverable, work backwards to define what things need to be done in order to complete the deliverable.  Clearly think in terms of deliverables which can easily be tracked as to completeness.  Continue to ask yourself, "For this task to be done, I need to have ________."

Equate logical task groupings to project deliverables -  As you break down project tasks try to equate sub-tasks to specific project deliverables.  As you define your workplan continue to ask yourself, "How will I know this task is complete?" and "What does the deliverable look like?".  By thinking in terms of deliverables you also better ensure that your tasks better reflect the work needing to be done.

Keep it current - As things change on your project make sure your workplan accurately reflects what needs to be performed.  Including stale tasks in your workplan creates confusion on the project team and leads to wasted time and money on your project.  Do remember to baseline your project prior to making changes so you can see a history of what has changed on the project.

Keep focused on the project objective - This almost sounds like a "no duh", but too many times project managers get so immersed in MS Project that they lose sight of why the project exists in the first place.  Keep the project objective prominently displayed as a reminder to you and the project team as to why you're doing the project in the first place.

Your project workplan is the backbone of your project.  Ensure the work is clearly articulated, easily understood, and succinctly addresses the project objective.  Fail to do so and you'll waste a ton of time and
money learning a painful lesson. 

It's Not My Fault! Free on Kindle 11/30 Only

Get my latest book It's Not My Fault!: 100 Ways Project Managers Throw Others Under the Bus free on Kindle 11/30 only. 
Get it at http://amzn.to/2fClxul

Using the Project Guide to define your project in Microsoft Project

A pretty nifty feature in Microsoft Project is the ability to define a project through the use of the project guide.  The project guide is a cool little wizard that walks you through setting up a project, assigning resources to the project, tracking progress, and reporting on progress.  What I like about this wizard is not only the help it gives newbie project managers, but also is a great reminder of the cool MS Project capabilities for more seasoned MS Project project managers.  

To get started with this cool project management software tool do the following:
Turn on the Project Guide:
On the Tools menu, click Options, and then click the Interface tab
In the Project Guide Settings, select the Display Project Guide check box 
You can also turn on and off in the View menu 

Define your project and tasks:
Define the project      
Define general working times
List the tasks in the project
Organize tasks into phases
Schedule tasks
Link to or attach more task information
Add columns of custom information
Set deadlines and constrain tasks
Identify risks to the project
Add documents to the project
Publish project information to the Web (if using project server)

Define your resources:
Specify people and equipment for the project
Specify the booking types for resources
Define working times for resources
Assign people and equipment to tasks
Link to or attach more resource information
Add columns of custom information
Publish project information to the web (if using project server)

Track and manage your project:
Save a baseline plan to compare with later versions
Prepare to track the progress of your project
Incorporate progress information into your project
Check the progress of the project
Make changes to the project
See what is driving the start date of the project
Track risks and issues associated with the project (if using project server)
Request text-based status reports (if using project server)
Publish project information to the web (if using project server)

Report status of your project:
Select a view or report
Change the content or order of information in a view
Change the look or content of the Gantt chart
Print current view as a report
See the status of multiple projects in project center (If using project server)
Compare progress against baseline work
See the project's critical tasks
See project risks and issues (if using project server)
See how resources time is allocated
See project costs
Publish project information to the web (if using project server)

Use this cool little project management software tool in MS Project to help ensure you're getting the most of what project management software has to offer!

Six-WOrd Lessons on Growing Up Autistic Free Kindle Download 11/16-17

Free Six-Word Lessons on Growing Up Autistic for Kindle 11/16-17! Get it at http://amzn.to/2eSEL1J 

Project Management Screw-Up 6 - The Team Didn't Gel

Excerpted from The Project Management Advisor - 18 Major Project Screw-Ups And How To Cut Them Off At The Pass (Prentice Hall, 2004)
I played the drums as a kid starting in fourth grade up into college. My family suffered through many hours (and headaches) of me beating the skins to jazz, funk, and rock music. When I started playing with the school band, I had to learn that making music wasn’t about how fast I could do flam-a-diddles or how loud I could play, but how I played in relation to the other band members. If the music called for adagio (slow & leisurely pace) it would be a bad idea to break into an In-A-Gadda-Da-Vida drum solo while everyone else is playing elevator music. 
The important thing was to match my playing to the other instrumentalists and to make beautiful music together. While I never got to rock stardom with my own entourage and groupies, I did learn that music is about how the entire band sounds -- not any individual player.
By now you’re probably wondering why I took a mental trip to Tahiti to tell you about my musical aspirations. To me, a well-structured project team where each team member understands their role in making the project successful is like the musicians playing in a band. Each project team member knows what they need to contribute to the project, when they have to perform, what other project team members are doing on the project, and what it takes to be successful. Just as important, each of the project team members helps each other to ensure overall project success.
How it happens:

There was not a clear project organization with clearly defined roles - This goes beyond a hierarchy chart. Each person needs to know what function they play on the team, how they fit into the other functions, and what happens if they don’t do their job.

Depending on your industry or functional discipline, there may be standard or customary roles that you employ on your project. There are a few things that I have learned, though, about project standard roles as follows:Start with the standard or customary roles that are typical for your type of projectsIf the project need warrants a special role which is outside of standard, create a special roleIf the project doesn’t need a standard or customary role, eliminate the role

These may sound like overly simplistic statements, but I’ve been amazed over the years with seeing cumbersome project role structures because the project manager was reluctant to deviate from standard project roles. As experienced project managers, our job first and foremost is to make sure that the right people are assigned to do the right tasks to produce the right result at the right time. At the end of the day, I’ve never been graded on how well I adhered to a standard project role structure; I’ve been graded on results.

If the project environment doesn’t have standard or customary project roles or if I’m taking on a unique type of project, I like to take a very pragmatic approach to role definition, as follows:Define the 3-6 things on the project that I am most concerned about or pose the greatest risk to meCreate roles that encompass the concern or risk areasCross-check the roles with the work that needs to be done in the project schedule to ensure that all the major roles are being defined correctly

By doing this, I am addressing concern or risk areas head-on by defining a role with a singular point of accountability to manage the areas of my project that are most likely to fail.  This technique has helped me on more than one project to sleep better knowing that I had my most crucial areas covered.

The team finger pointed and fought in public - On any project you do, so long as there is more than one person involved, there are going to be lively discussions. When this happens, it is very likely that something good will come of the discussion and that in some way the project will move one step closer to the finish line as a result. On past projects I have managed, I was very deliberate about letting these discussions happen and in letting team members question each other. I did put a few rules in place, though:It’s very cool to challenge and stretch, but when we make a decision we need to get behind it as a teamWhat happens in the room stays in the room; outside of the room we are a unified teamIf we made a wrong decision we accept the decision as a team; no finger pointing allowedWe focus on the problem and not the person; don’t make the problem personal

So, were the rules followed 100% of the time? Sadly, no (myself included). After all, we are human. However, you should still strive to get some ground rules in place to avoid team strife where you can.

There was no “rallying cry” - You can look at many major successful campaigns and pull some slogans from them which embodied the message behind the slogan: “Where’s the beef,” “Milk, it does a body good,” and “Plop, plop, fizz, fizz” are all unifying messages that cause you to think about a product. Similarly, when driving a project it helps the team to have some kind of a rallying cry or mantra that the team embodies when driving work. On one project, we wanted to be extremely cautious of not over-designing a solution and putting too many bells and whistles in to help us keep our costs down. We started using a “good enough” rallying cry during the design phase to be a continual reminder that we wanted to not overdo the solution. It worked incredibly well because the team would critically question itself with “Is this good enough?” when looking at the architecture and functionality. Aside from helping to make sure that our solution was cost effective, the rallying cry helped the team to better bond.

Team members weren’t held accountable for delivery - With project teams, I firmly believe that each role needs to clearly understand what they need to do, when they need it done by, and how their work fits into the big picture. I also firmly believe the project team isn’t only accountable to the project manager, they are accountable to each other because if any of the other roles fail the entire team fails. Given so, it is vitally important for each role to be visible as to what each other role is doing for the following reasons:Each role should be continually looking at other work that is happening to ensure that they know if and how they fit into the other workEach role should feel that if they miss a deadline or do not perform their job adequately, they are letting down the team as a whole, not just the project manager.Meeting or missing deadlines and deliverables are a team issue and should be exposed to the team.

The point here is accountability. Each member needs to feel accountable for their work and needs to experience the joy of success as well as the discomfort of failure. The project manager needs to use discretion on making sure that things do stay constructive. Focus should be very much on how the team gets things back on track and moving forward versus badgering the team member.

In some instances, though, you may just have someone in a job who is not suited to perform. The project manager needs to deal with those situations swiftly because if he or she doesn’t, he or she is not doing his job nor being accountable to the team by dealing with a problem performer.

The project manager wasn’t suited for the job - The project’s needs and criticality to the business will be key drivers in the required experience level of the project manager. For relatively simple projects, you may be able to staff the project with an inexperienced project manager with a more seasoned project manager serving as an occasional mentor. As projects increase in complexity and criticality to the business, though, there’s no substitute for an experienced, seasoned project manager.

I’ve been incredibly fortunate to have worked with some outstanding project managers over the years. In thinking about the best project managers, they’ve had the following things in common:They knew the techniques of project management coldThey knew (through experience) where they could bend the rules on the techniques to be able to buy time or be more efficientThey always kept things moving forwardThey knew when to shift from “let’s discuss” mode to “let’s decide” modeThey held others accountable to do their jobsThey praised successThey were excellent communicatorsThey took the heat for the team when external criticism happenedThey were calm and focused when things started going bad on a project and everyone else was wigging out

I know of no magic formula for fitting the project manager for the job; what I can say is you’re better to err on having an over-experienced project manager versus an under-experienced one.

I knew of a very gung-ho young project manager (let’s just call him “Author”) who felt he was an outstanding project manager because he knew the techniques well (cost and schedule management, status reporting, and so on). Because Author knew the techniques, he felt he could simultaneously take on three complex projects that really should have each had a dedicated project manager. Not only did Author learn some very valuable lessons, he unfortunately also cost his company a lot of money because others had to come in and mop up his mess. Both Author and I can’t stress enough to make sure your project manager is suited for the job.

The team didn’t celebrate wins - Driving through a project is tough work. It is incredibly easy for people to get discouraged whenever the team hits roadblocks or has setbacks. It is vitally important for a team to celebrate hitting key milestones simply to keep morale up and keep project momentum. I’m not talking about three-day cruise type celebrations, it could be as simple as bringing in pizza or cake or something that allows people to let their hair down and take a bit of a breather. I would caution you about doing this too much; doing too much celebration lessens the effect of the celebration and could actually annoy your team members. I was on one project where people did not like the morale events because it only meant that they had to stay later that evening to get their work done. So, celebrate, but do it in moderation.

Warning Signs:

The team shows confusion about who is doing what - Confusion can exist either due to poor communication on who is responsible for what tasks or because tasks can reside under the responsibility of more than one role. It’s important not only to get people to agree on areas of responsibility, but to ensure that the responsibilities are clearly documented and communicated to the entire project team. Also, be prepared to pull this document out and remind the team of its respective responsibilities as confusion creeps back into the project team.

Discussions are destructive and unproductive - You know what this looks like; if you’re team can’t have discussions without getting personal, derogatory, or outright mean this is a pretty clear sign you’re not gelling as a team. The project team doesn’t have to be best friends with each other, but they should at least respect what each other bring to the table.

Team members aren’t helping each other - I’ve actually been in some environments as a consultant where some team members enjoyed seeing other team members fail and did absolutely nothing to help them for the good of the project. Project team members who carry an “every person for themselves” kind of attitude are not going to perform anywhere near their full potential.

Turning it around:

Clarify the confusion - Get team members locked in a room and hammer this out. If you get stuck on a particularly contentious area or if you see tempers flaring, set it aside and work on other things, then come back to the contentious area. Make sure that responsibilities are documented and clearly accessible for all members.

Address the problem team member - Never a pleasant task, but I on more than one occasion have had a project team member taken off the project because they simply were going to remain a destructive force on the project. At the same time, I’ve also been able to turn a destructive situation around. In either event, address the issue swiftly before it does further damage to the rest of the project team.

Co-locate the team - I’ve had some of my greatest successes where the project team was physically located in the same area and had minimal physical barriers to inhibit communication. This may or may not be entirely possible depending on your project, but where you have the opportunity to co-locate team members, strongly consider doing so.

Go out for a milkshake - Sometimes it’s great to just get people away from their work environment and socialize over a favorite food and beverage. As a consultant on out-of-town projects, our project teams were typically very effective because we had more time to socialize and bond during non-work hours. Getting to know each other a bit and being able to laugh as a team pays huge dividends in overall team effectiveness.

All work and no play…- ...makes for a really dull and demotivating project. Take some time out of the project to have a laugh. I have certainly been known to play an occasional practical joke on a project or to bring some occasional levity to a particularly stressful time in a project. Just be careful that the use of humor isn’t too excessive or inappropriate; but by all means make sure that you share a laugh or two even if it’s at your expense.

Be the unifier - As the project manager, you are expected to take responsibility for getting the team to gel and to know the barriers that exist which are preventing the team from being a highly cohesive, collaborative, high-performance team. At times, it’s likely to be the most uncomfortable part of your job, but it can also be one of the most rewarding when done well.

Take Aways:Define a clear project organization with clearly defined rolesBe a team through thick and thin; don’t publicly finger-point when things start going southDevelop a “rallying cry” which focuses the team on the missionLet the team members do their jobs, but hold them accountable for results and datesMake sure that you have a project manager that who is appropriately seasoned for the projectCelebrate the wins as a team