What "Project Manage" Meant

I've moved up the food chain! I am no longer a lowly controls technician, I am now a semi-lowly controls engineer! I am salaried, a tad richer, a modicum more respectable (who, me?) and a whole lot more burdened

(It's funny, I ought to be nervous, but I'm just too excited about it to succumb to fear).

A brief aside - this group here has been instrumental in just about every single success I've experienced, and I want to say, from the bottom of my heart, thank you all, and thank you Phil for having us.

Now, they say that the job of a governer is to become a senator, and the job of a senator is to become President, so I'm already thinking 3 or 4 years down the road, when the Tech Manager position starts looking like a nice fit.

(Huh, last week my loftiest goal was talking Unitronics into supporting Profibus...)

But to acheive that goal, the first thing I have to do is prove I can manage my own projects effectively and efficiently. Up till now, 90% of my work was for other people, but now I have jobs of my own to do - on TOP of all my work for other people.

So I'm looking for information on project management techniques. I read this spiffy article at Wikipedia

http://en.wikipedia.org/wiki/Project_management

And had no idea it was this involved. I've checked out some software - I've been using Freemind to track index my project files and notes for a while now, and it works really well.

I have a few questions:

1. What techniques and tools do you use to manage your automation projects? Gantt charts? Mind Maps? Post-it notes?

2. What variables do you find important to track, and how granular do you get? For instance, when tracking time, do you keep a general count of hours, divide your hours by task, or do you carry a stop watch around?

I'm sure I'll think of more later

Thanks!

TM

Congrats tim

Congratulations Tim, wish You More Great Success

Congratulations on your promotion!

I would advise you start by getting a Day Planner that you can jot notes down (as they come to you or in meetings), list tasks that need to be done (from your notes), phone numbers/emails of others that are involved; something that you can write and organize your thoughts on that you can refer back to later.

IMO, this is the key to not letting anything slip off the radar screen in a project. Yeah, some of the software organizers can be good, but its clumsy and distracting to drag around a laptop to meetings, or when traveling. I find it more efficient to just write stuff down, diagrams, etc. and if I need to put in some kind of software package like Microsoft Project or Excel, I can do so later.

Good luck! -Jeff

Relax, you aren't building the Golden Gate bridge.

TimothyMoulder said:

I have a few questions:

1. What techniques and tools do you use to manage your automation projects? Gantt charts? Mind Maps? Post-it notes?

Click to expand...

I have never used anything fancy. It is good to have a sequence of events. It is poor to wait for something obvious. Keep as much moving in parallel as possible.

TimothyMoulder said:

2. What variables do you find important to track, and how granular do you get? For instance, when tracking time, do you keep a general count of hours, divide your hours by task, or do you carry a stop watch around?

Click to expand...

Don't carry a stop watch. You will drive people nuts. Back when I was doing software by myself and actually doing computer systems I could estimate very accurately how much time everything would take. I was the changes, changes to the changes and feature creep that slowed things down and ruined schedules. Get the scope of work and definition of the final goal defined before making estimates. What management doesn't always realize is that some changes are simple and don't take much time whereas others are impossible.

You also have to know when you don't know. I have seen some pretty stupid and very expensive mistakes. Get help when necessary. Sometime a phone call or a post on a forum can keep you from making a mistake even if you don't get the optimal
answer.

Don't be afraid to spend money to reduce risk and increase productivity. Things like a good scope are a must. So is knowing how to use one. When doing a lot of programming I like big screens. I like the new 24 inch LCD monitors mounted vertically to display code or ladder. This pays for itself in no time.

Have a plan to back up code changes and keeping track of code changes.

Don't be afraid to share your knowledge. Others will share theirs. This will make everyone better. I spend a lot of time training others. Usually this is in small 15-30 minute sessions.

Have some PLCs and other equipment that you can experiment with. Use these for training. Spares will do in a pinch. Spares don't do any good on the shelf.

Training, no matter how trivial, if contuous, will be effective. I am paraphrasing something I learned in the navy. You can replace the word training with anything you want.

Changes can be made in very small increments too. Sometimes you can't change as fast as you want. Even small improvement can help pay for future small improvements.

0. Don't do anything stupid
1. Make it easy to do right.
2. Make if hard to do wrong.
3. Just becase you can doesn't mean you should.

Advice for TM from someone who is actually not that good at managing projects (but I am getting better).
I have been on several project management courses, and they are all based on the PMBOK (look it up).
The three main areas to look out for are (in random order):
1, Scope
2, Time
3, Cost.
The PMBOK has additional areas, which you should probably move into once you have mastered the above three. Also, as far as which is the most important area, that depends on what is in short supply. Generally you will know from the start what is most important to watch, but all must be watched.
My management tools are:
1, A project scope written in MS word. I write mine in point form and have the end user sign off on the points before starting anything else. You must cover what the project will deliver and, more importantly, what it will not deliver. This can then be used as a checklist and negotiating point. At the end of the project, ideally, all items will be covered off. Also listed in the scope are any constraints that you know about, any risks that could occur and any assumptions that you have made.
A good scope is necessary (but not sufficient) for a good project. A bad (or no) scope always results in a bad project.

2, Time. I generally use MS project for this, although since I don't use all the features of MS project, I could probably get away with using Gnatt project (which is free ware open source). First, define each of the project steps, going as detailed as you think is appropriate. Estimate a time for each of these and determine which tasks are dependant on other tasks and which can be done independantly. Assign resources, taking care that you accurately know what resources you have and when these are being used elsewhere or are otherwise un-available. You can then see how long your project will take. You then check to see if there are any time constraints (such as the project must be completed by next week or we are all sacked!). If there are, you may need to adjust the tasks to bring the project within time.
3, Cost, with the scope and timeline done, you can now estimate the cost. I tend to use Excel for this. I have tried MS project, but that does not seem to work very well for this. Often, you will get a constraint on costs, such as "this project must cost less than $100K". If your costs overrun, then you must trim them somehow.

These three items need careful balancing, and usually one or two of the items are fixed and the third has to move.

This was only a light touch of the field, but I hope it gives you a pointer on developing your own style.

Good luck with your future,

Doug

Edited to correct the worst spelling (and I spelt MS project as "MS Word" I am tired and spent all night in the factory)

Have a look at "The Mythical Man Month" by Brooks - although this was written some 30 years ago, most of the points made are still very relevant today.

Excerpt from The Mythical Man-Month

Why is programming fun? What delights may its practioner expect as his reward?

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctiveness of each leaf and each snowflake.

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office."

Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.

Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this tractability has its own problems.)

So… does this mean Terry is a poet also……imagine that….

Congrats on the career upgrade! I wish you much success. Like several people have already said, I don't do much special. I generally drag a spiral notebook around with me that I use for all notes, diagrams, etc. Everything eventually gets moved to Word, Excel, AutoCAD, etc. I have a file of full notebooks that I can refer back to later on if I need to see what was originally written down. It's basically going to boil down to creating a system you can use effectively. If you won't be able to keep up with a cumbersome software package to manage everything, it'll either become a major annoyance to do it, or you'll just give up on it. Just my $.02

Tim,

A belated congrats on your promotion.

There has been some good advice with regards to staying on top of your projects. What will probably happen, is that you will take a number of these ideas and incorporate them in to what works best for you. Remember, whatever you end up doing, it has to work for you.

Pick the brains of others at your company as well. Your corporate structure may also factor in how you need to do your project planning.

One thing that you need to be prepared for, even though you can't totally prepare for it, is the unexpected.

To give you an example, We are currently doing a programming project that incorporates a touch screen with one of our PLCs. Based on the schematic we received, we estimated 70 hours for combined programming (45 individual screens with macros). When we thought we were nearly done with the project, we noticed that there were three areas that were not fully developed by the customer. It turned out that he had been put on another project himself and forgot that it needed to be completed. Needless to say, we were at our estimated hours and figured that there wouldn't be that many additional screens based on the other related sections of the schematic. Boy...were we wrong....there were another 105 screens that would also require macros. A project that was close to being done, would require another month of development.


It is always possible that something will fall through the cracks, something is omitted from the spec., or one of your senior managers may change project priority with little notice.

From a management perspective, you may also have to deliver news that may be unpalatable. Make certain that you have your documentation in order to support your position.


Therefore, make certain that your planning is flexible and well documented. A plan that you consider to be fixed, could hurt you, and only put you further behind.

Hope this helps.

God Bless,

There is a lot of project management software out there, much of it way to complex for most projects. I've heard that MicroSoft Project is fairly easy to use, and suitable for most applications.

The most useful planning tool in my experience is a Gantt Chart. This is set up by breaking the work into tasks, assigning cost, time, and labor requirements for each task, and then putting it on a chart. Most project planning software will do this, plus identify the "critical path" that determines the items that will cause your project to get off track the fastest.

There are also critical path charts and such, but they are not easily interptreted.

The key factor is to make a list of steps, and keep track of where you are. This can even be done with a simple spreadsheet.

TM,

One of the simple, most effective tools that I have ever found is a filing cabinet, with a file folder for each project. Drawings, notes, schedules, and programs all go into the file folder. I have folders going back years, that I refer to often.

The project schedule methods, such as Gnatt, Critical Path, Milestone, Microsoft Project, will work wonders only if used correctly. The key for all these methods is this: The people that are going to do each task MUST agree to the proposed schedule. Once that is accomplished, the completion date is almost fixed in concrete. If everyone involved has "signed off" on what is expected of him or his group, then success is assured.

On the other hand, the way these charts are typically made, some project engineer is told to "come up with a schedule for this project" S/he sits in an office all alone and makes guesses about what OTHER people will or will not do. Big mistake!

Once a reliable person has given his word that so-and-so can be done, then he will bust his bottom to make it happen. But if he was not even consulted about the job, how can you expect him to do what YOU said he could do?

Get some sort of calender to write down when someone said they would get back to you or when someone said something would be ready/shipping whatever. That's the hardest part to me is remembering to check on whether something happened that someone said would happen. Some people use a calender on their wall, some just keep notes in a notebook, I use a day timer that I can carry with me. When someone says something will be done by a certain time make a note to call them back and check on it (I usually give them a few days of extra time unless time is critical).

Also, keep a notebook next to the phone. Keep a phone log of all calls and what was discussed - sometimes people need their memory jogged as to what they said and when.

Also I second the advice given above - learn to know when you don't know. No one know everything, don't go to far down a path blind, once you go past a certain point it gets expensive to backtrack.

Most of all - have fun! Take some time out every now and then during the day to tell a joke or listen to one. This helps keep everything in perspective and keeps the stress level down!

Google "Theory of Constraints". Buy a book on Amazon. Take the basic principles and apply what you can.

I am learning how to apply this type of management to my own projects. Basically it teaches you how to prioritize the resources that you have, to support the critical tasks that are causing bottlenecks in your schedule. Most managers over-manipulate things that have little impact on the final outcome. If you can identify the critical chain of tasks and events, then subordinate your resources to support those, you will find that you don't need to manage other things quite so tightly. This makes your job much easier, and the project runs more efficiently.

This can get extremely complicated with lots of advanced techniques, tools, and software; but the principles are relatively simple. If you can keep them in mind, and use tools that you are comfortable with (spreadsheets, stopwatches, whatever), then you will be a much more efficient manager.

$

Congrats on the title. The things I found worked best for me when I was Mod Shop Project Mgr. was to write everything down, keep a record of everything and file everything in its own pile. I was primarily doing all the admin stuff and keeping the engineers free to actually design.

The file folders Lancie1 suggested were along the lines I used. You will be doing multiple projects and like it or not, you will not be able to remember every detail of each project. I keep a note pad in my shirt pocket for quick notes. I keep important phone numbers in the back of it. As long as I have that note book I cannot forget the important things. Then I put any inportant information into the appropriate job folder. I had a stack of routing baskets for the daily paperwork that occured with each project. I put all hand drawings, notes, PO's, packing slips, time sheets, mfgr. instructions sheets that came with the parts, etc.

I was required to use a gant type chart to track the projects. It does help large departments but I proved for 3 of us it was a time consumer on my part to keep it up. At least once a day take the time to review all of your projects, it helps even if you do not do anything on some of them. At least once a week, get all of your documentation current, NO MATTER WHAT. Documentation that is not current will bite thee on thy buttocks with extreme prejudice.

MOST OF ALL, step back take a deep breath and relax. Do not sweat the small stuff. And ALL of it is SMALL.

DDV said...
"So… does this mean Terry is a poet also……imagine that…."

As a matter of fact, yes... I am a poet... a poet in motion control without relying on exotic controllers... to the extent that I can.

Without a doubt, there are situations that require a hard-core, highly-timing-sensitive, technical solution, provided by a specialized solution-provider, which are technically beyond the capabilities of a typical PLC.

Up to that point... I can do the poet thing on most situations.

It's simply a game of cause, effect, and... time... and being able to mentally EXPAND "time" to whatever scale is necessary, and attainable.

Beyond that... you had better talk to Peter.