Starters vs. Closers

Are you a Starter or a Closer?

Starters

1. Arrive at work with no set goals for the day. You would like to get something done, but don't have a plan.
2. Spend most days adjusting to the time demands of others. Your agenda is set for you, not by you.
3. Typically have many tasks in progress at any one time. And they're ALL important.
4. Prefer to do things yourself, rather than delegate them, because others wouldn't do as good a job as you would (if you had the time).
5. Intentions are noble, but deadlines are frequently missed.
6. Always find the time to begin a new task, but can't find the time to complete an existing one.
7. Have difficulty saying "No" to others' demands.
8. Are more of a "go with the flow" person than someone who "makes waves".
9. Hold the belief that if you're putting in 40 (or more) hours of work, you're doing your job.
10. Tend to do more "gathering of information and reporting" than "doing".
11. Count meetings as "work" - even if they don't accomplish anything.
12. Spend a portion of every day explaining to others why something isn't done yet.
13. Tend to be an individual problem solver and tend to "reinvent the wheel".
14. Starters try to eat the whole elephant in one sitting. You see large projects as daunting, difficult and have difficulty breaking a project into smaller manageable tasks.


Closers

1. Arrive at work knowing exactly what needs to get done.
2. Are in control of their daily schedule - will refuse (or counter-propose) meetings if they jeopardize a deadline.
3. Are focused on a few important tasks and have the discipline to defer less important tasks.
4. Can effectively delegate tasks and get things accomplished with their team. They understand that even if the task might not be (initially) done to their standards, that providing a learning opportunity to a junior member of the team will both advance the completion of the task and better prepare your team for the next one.
5. Deadlines are personal. Making and meeting a commitment is very important to you. Your reputation is on the line.
6. Are comfortable with prioritizing and helping others understand the difference between important projects and urgent projects.
7. Can gracefully say No to a request (or Yes, but not until Task A,B and C are completed).
8. You measure your job performance in terms of tasks and projects completed, rather than time spent.
9. You understand that by focusing on completing Project tasks on time, that the overall Project deadlines (milestones) manage themselves.
10. You are selfish with your time. If you're invited to a meeting that doesn't have a specific objective you ask the organizer for the meeting objective or don't attend. Not all meetings are bad. Just the ones that don't accomplish anything.
11. You're focused on the future but working in the present. (How do I get this task finished to get on with the next one?)
12. You want to get to the answer quickly. Don't have a problem in asking for expert advice if it moves the project forward. It's the answer that's important, not who provides it.
13. You view projects as the sum of their tasks.

The "Magic" of Getting Things Done

I am continually amazed at how often people fail to demonstrate the ability to "get stuff done".

Some call it a failure of leadership. Some say it's due to a lack of organization. Or maybe it's simply poor implementation skills. Or a lack of a coherent strategic vision.

Truth is, it could be any (or all) of these things.

I am not an expert, but I have learned a few things over the years.

The first, is. If you have ten #1 priorities, you don't have any priorities at all. You simply have a list. And the problem with an unprioritized big list, is that it allows those responsible for the list to "touch" each task, without ever moving any single one forward significantly. The "overhead" it takes to juggle ten initiatives soaks up valuable time you could be spending on completing a task.

So, prioritize. If necessary, trim the list to a few key items. The rest can wait. Truth is, you're not making much progress on them anyway, so where's the harm?

The second rule is to assign ownership to each task. If a "team" is responsible for the completion of a task, no ONE person owns the outcome. And so each team member gains comfort in the thought that a lack of progress is probably someone else's fault.

Thirdly, ask yourself, "Have I engaged the right resources?" For example, if you're undertaking a revamp of your Job Costing processes, do you include shop floor supervisors who collect and assign labor costs? Is purchasing involved? Receiving? Accounting? Do you need someone from payroll to verify that labor hours assigned to jobs balance to payroll hours? Identifying all the process "touch points" and securing the involvement of expertise from all areas, is a basic requirement to move forward in any substantive way.

Fourth, "paint the picture". Help your team understand why this initiative is a priority. Paint the picture of what the future process might look like - what the business benefits of improvement are. Establish buy-in from the team. Remember that these people already have full time jobs. Just because they're on your team doesn't mean you have their support or buy-in. At the end of the day, each participant should be able to understand "what's in it for me?"

Fifth, parse the project. Large change initiatives are scary and daunting. If you can break up your project into manageable and easily understood milestones, you improve team understanding of each task and can easily measure progress. I always think of the old joke: How do you eat an elephant? (Answer: One bite at a time.)

Sixth. Spend your time executing the tasks, not managing the project. Use tools that allow for simple collaboration and project updating (SharePoint, Basecamp, Google Docs) - whatever works for you. This will allow you less time in meeting updates and more time to address issues and make decisions.

Careful observers of these rules will have, by now, understood the "magic" of getting things done. Design your project by providing answers to the questions: Who, What, When, Where, Why and How?

Tips for Project Managers

Here's an interesting presentation that all Project Managers should watch....



Do you have any tips to add?

Business Led or You're Dead

Somewhere in the midwest, storm clouds are brewing over yet another ERP implementation project. In about six weeks, when the project is expected to go live, the ABC company (name changed to protect the guilty) will learn that many of the process decisions they've made are wrong. The new automated processes will actually be slower and more cumbersome than current processes. Their staff will be completely unprepared. Things will grind to a halt.

It will be an unmitigated disaster.

How do I know this? Unlike the company, I spent an hour or so listening to the Project Manager.
His client company is a leader in its industry. Their past success is making them "hard of hearing". "Just make the system do what we've always done." they say.

Which should beg the question; "Why not stick with the legacy system?"

What they don't understand is that to achieve meaninful improvements, you actually need to change something.

ABC's expectation is that by simply installing a world class ERP system, their processes and operational performance will improve as a result. Nothing could be further from the truth.

That same reasoning would have you purchase a pair of Air Jordan basketball shoes with the expectation that you'll be playing guard for the Chicago Bulls.

Not gonna happen.

Operational excellence is achieved with three ingredents; great people, great processes and the right tools. A new ERP system is just a tool. Just one componant.

Installing a new system is an opportunity to re-examine the way your company does things. A chance to simplify, to optimize, to take a fresh look at the way things are done. It's a chance to re-educate yourself in how your company processes work. If you don't do this on a regular basis, you'll be surprised at the difference in the way you think processes work and they way they're actually done.

Reviewing processes takes a big investment in time and resources - business resources. Unless the project is business led, you simply can't pry loose the key people who can make a big positive difference in the outcome. Everyone is too busy "doing their regular jobs" to devote any time on the project.

It's the Number 1 reason ERP projects fail.

(Shameless plug) If your company is contemplating a major I.T. project in the near future, may I suggest you check out my e-Book entitled; "Lessons Learned from the ERP Frontline".

It's available by either clicking on the Lulu link on this website or by going to http://www.lulu.com/ and searching on my name or the title.

And best of all, it's free.

The Power of Surveys

I'm a fan of surveys.

I've used surveys throughout my career to help me gauge helpdesk customer satisfaction, effectiveness of communications/training and sometimes to determine how well an I.T. project is going (from my customers' perspective). There are dozens of survey tools available, but typically I use Survey Monkey for its ease of use..

I only have a few rules about surveying.

1. Surveys should be made of not more than 8, clear, concise, unambiguous, well thought out questions.
2. Each survey should take less than 2 minutes to complete.
3. The survey results are always shared with my team and my customers, usually posted on a portal for everyone to see - whether good news or bad.
4. Most times, the last survey question is an open ended one. How can we improve? (the experience, process, training or communications).
5. I usually allow anonymous responses (I send out the invitations to specific invitees, but don't track the responses by individual). I really believe it allows for more open, honest feedback.

As long as you limit your surveys to important issues and don't spam your employees or customers, my experience is that most people will fill them out.

Sometimes you find out more than you bargained for.

We were conducting a post system implementation review and wanted to find out how our customers' "go live" experiences were. While I knew that many sites were struggling with the new system, I suspected that part of the reason was the (low) level of priority that local management had given to preparing for the project.

And so I did something a little sneaky.

I prepared one survey, but sent it to two distinct groups; Managers and End Users. The survey results for the two groups were pretty consistent until we reached a question about site readiness for the "go live".

While the majority of management thought their sites were well prepared, 85% of their employees felt they weren't! We identified a clear disconnect between site management perceptions and those of their staff.

Based upon the open ended question at the end of the survey, it was clear that the site management were not nearly engaged as they said they were. According to employee comments, managers rarely spoke about the importance of the project, never updated employees on progress and didn't allow adequate (or in some cases ANY) training practice time for the employees to get comfortable with the new system.

While we conducted site readiness assessments before we went live, we made the mistake of asking the managers only.

Lesson learned.

Too Many Times, it's True....

Thanks to 800CEOREAD.com who points us to this site.

Project Cartoon is a variant on the classic I.T. Project cartoon, which (accurately) displays the various facets and views of how typical I.T. projects are run.

Now, thanks to the Project Cartoon site, you can create your own version of this classic cartoon by dragging and dropping the images and providing your own captions. Print it out and display it on your office wall.

Have someone from your user community visit the site, create a cartoon and send it to you. You could learn a lot about what your customers think about your PM skills.