Well, we are fast approaching that time again. My three or four loyal blog readers know that I make Christmas cookies. And, we aren’t just talking about a couple of dozen, either. I made well over a thousand cookies last year, and this year’s quantity may be an all-time high. I have to send a couple of batches overseas, some to my daughter away at school, some to her friends away at school, and more requests from people we know. We always seem to have more friends at this time of year!
But this yearly adventure in my life points me back to a little project management and manufacturing runs. A successful project or manufacturing process starts with three basic questions:
- What do we need to do?
- How are we going to do it?
- What is the timeframe?
In a manufacturing environment, it is sometimes easier to answer the last question first as, more often than not, a market exists for the product. To determine your start date and the feasibility of this process, calculate the lead-times for the raw materials, find the absolute drop-dead date for the product, and work backwards. So, WHEN you need to finish will dictate WHEN you need to start and WHEN you need to order stuff. In this cookie scenario, I am a little squeezed on time because I have to get the “international” shipments and the college packages ready by the last week in November. The time to create the cookies is known. The steps are simple: get the raw materials (ingredients), follow the recipes, bake, store, package, and distribute. In real life, it may be more like: order the raw materials, wait for them to arrive, call your suppliers when they are late, wait some more, call again, unload the product, return the product as it is not what you ordered, wait… When you finally get what you need, you start the manufacturing process. However, your widget maker breaks down because it needed maintenance, and you had no idea when it was last serviced. The part you need is backordered. You wait, your customers are screaming, your sales people are hiding. I have it easy at home in my kitchen.
- Why do you need to do this?
- What are the compelling reasons or arguments for this project?
- Who are the stakeholders involved?
- What are the goals?
- What is a successful project?
Once all of the above is defined, the “HOW we get there” is a little more complex. This is your guideline, your playbook. Everything in it has to be defined. Do not leave anything open to interpretation. Also, the last question, WHEN, will play a key role in this section. You or the customer may need to get more personnel, may have to prioritize other projects or roles, or may have to secure a place in the schedule.
- Define what is in place already
- Define what applications, functions, files, jobs will be affected
- Define who will be using the application(s)
- Define the application parameters
- Define the interfaces, files structures, reports, screens, security, backup/recovery, etc.
- Define the roles and responsibilities
- Define the documentation and training
- Define the timelines, deadlines, and milestones
- Define up-front costs, development costs, implementation costs, service and maintenance
- Define the payment schedule
- Get signed agreements
Do not start a project until everything is defined and until everything is answered. Your deliverable of a project plan will detail all of this, but it is important that any ambiguities or vagueness of the information will affect the project, and usually not in a positive manner. The bottom line is: get as much information as you can up front, and the project will run more smoothly. I should have said that 600 words ago. Oh well.
If you need assistance on project planning, let us help you out. We closely follow the Microsoft Sure-Step guidelines, and we have had success with small to large rollouts of manufacturing software and equipment. Heck, we also can make a ton of cookies, while we’re at it!
Happy Holidays!
