It is essential that you get busy immediately, because you cannot plan realistically until you understand the work required. You should organize your group’s resources quickly: database manipulation, CAD drawing, programming skills, report writing, presentation, etc. Make sure you can communicate with each other reliably and quickly.
Here is a calendar of milestones by which you can manage your work:
|By week 2
||Appoint leaders, form groups. Determine resources, such
as who can write, present, program, who knows databases,
|By week 3
||Client visit, presentation
|By week 4
||Preliminary definition of project; data request to
client. Prepare tools for data examination, manipulation.
|By week 5
||Receive data. Check for irregularities. Prepare summary.
|By week 6
||Refinement of project goals; schedule for remainder of
project, assignment of tasks within group
|By week 10
||Finish tool-building, large-scale data analysis.
|By week 12
||Final runs of any large data analyses, simulations,
|By week 14
||Draft of project report, presentation
|By Week 15
||Organize and package all tools, documentation for client.
|On Week 16
||Presentations, submission of final report
Do not contact the client directly.
Instead, send any questions to me. I will collate them, forward them to the client and distribute the replies.
It is okay for one group to use the results or work of another, so long as the source is properly cited. I recommend that you share information about the client, but keep your own analysis to yourself.
- Each group will make a 30-minute presentation, including questions, as scheduled in the class calendar. At the time of the presentation, you must submit four paper copies, in color, of your presentation slides. These should be printed 2 or 3 to a page, with space on which to take notes, and bound or stapled.
- Four copies of a bound or stapled executive summary, not to exceed 10 pages, written for the client.
- Four copies on a memory stick or CD containing all your work, including the presentation, executive summary, appendices, figures, graphs, spreadsheets, databases, computer programs and source code, etc. — in short, everything necessary for the client to follow every step of your work and to reconstruct your conclusions or extend your analysis. Your final report should include links to all supporting materials along with descriptions of what they are. The name of the main file should follow the convention
YYYYMM is the year and month of your presentation and
N is your team number. If you use a CD, make sure it is in a protective case and that the case is labeled
- Each group leader should also send me email listing the relative contributions of his/her group members: Rate each one as Extraordinary, Satisfactory, or Seriously Deficient. If other than Satisfactory, please support your rating with a detailed justification of at least 200 words.
You may need to bring more than four copies of each of the above, depending on how many representatives the client brings. This will be determined close to the time of presentation.
All of the deliverables are due at the time of presentation.
Each group will be graded on technical excellence, professionalism, and ability to work together. Group leaders will help me in evaluating the contributions of the group members. If you experience problems, contact me immediately. It is too late to do anything if I do not hear about the problem until the end of the project.
Note that all material is testable on the final exam. Each group member is expected to know about all aspects of the groups tools, techniques, and conclusions. For example, if the group wrote SQL queries to manipulate data then everyone in the group is responsible for understanding what was done and why.
Everyone is expected to attend each presentation, including those of other groups. Because presentation time will be short, please arrive promptly, take a seat, and remain quiet. If you have to leave the classroom for some reason, please do so as quietly and unobtrusively as possible.
The material displayed in the final presentations are part of the course material and may appear on any final exam.
Advice on the presentation and final report
Your presentation is the single most important deliverable.
It is the only chance to engage your client directly and will determine a large part of your project grade. If you make a bad impression, it is almost impossible to recover.
- It is best to rely on a single person to present your work. The speaker does not have to be able to answer all questions; they can call on teammates if necessary.
- Face your audience, not the projection screen, when speaking.
- Plan to talk for only 20 minutes and leave 10 minutes for questions. This means you should use no more than 10-15 slides.
- Use mostly slides with figures. Avoid tables if possible. Keep text to fewer than 6–8 lines of text per slide.
- Number your slides so that the client can easily refer back to specific pages.
- Talk about the client and his/her problems, not about yourselves and what you did.
- There is no need to tell the client who they are, who you are, etc. They know.
- Do not use technical terminology that is likely to be unfamiliar to your client.
- Use familiar units-of-measure. For example, use person-hours instead of person-seconds.
- Structure your report so that alternatives can easily be compared. This means that alternatives should be presented in the same units-of-measure, same scale, etc.
- Do not display any statistics that are obviously bogus; this just advertises that you did not resolve inconsistencies in the data or in your methodology.
- It is not enough simply to suggest changes. You must estimate the results of those changes, as well as the cost of implementing the changes. Cost can be in dollars or person-hours or whatever unit of measure seems most natural.
- In evaluating any suggested changes, be sure to discuss implications of the change on both upstream, downstream, and parallel processes.
- Use carefully-designed graphics to summarize your ideas for the client. In fact, try to speak only from figures and charts, without using bullet points.
- If you use a simulation, give the client some reason to trust the simulation. For example, benchmark it by comparing predictions with some verifiable statistics from the actual warehouse.
- Be suspicious of huge improvements. If there is an opportunity to improve by 40%, there is a good chance your client will have thought of this already, so you may have missed other issues involved. Find out what they are.
- Try to structure recommendations in layers, starting with simple, inexpensive improvements to current system and progressing to improvements that require more investment or return less value.
- Practice your talk in advance. Make sure in advance that the projection system works as you expect.
- Ruthlessly edit out any mention of “we” from your report. This is about the client, not about you.
Suggested first steps
- Focus on the problem as described by your client. Do not assume that the tools and models we develop in class are necessarily right for the problem. One of the most interesting challenges of the projects is that they always require something new.
- Look at the data immediately. Try to understand what is happening in the warehouse and what additional information you might need.
- Secure a computer with a database program and some general programming language. Choose one that is supported by the client. If you choose some other language, be prepared to explain why, in terms of the client’s requirements. “Because I already know language X” is not an adequate reason.
- Think about what additional data you would like from the client. Structure this in layers: What would you like to have ideally? What can you work with if the ideal is not available?
- As soon as you have data, generate some initial statistics to check for plausibility. For example: How many orders per day? How many lines per order? What are the ten most popular sku’s? Ten least popular? What are the most/least popular vendors? You may find it easier to get started if you use only a portion of the order history at first (for example, data for one month). This will make it easier to debug your tools and get involved with the data. Afterwards you can run your tools on the complete data set.
- In the file of skus, break the storage addresses apart so that you have a separate field for each component (zone, aisle, section, shelf). This will allow you to locate sku’s to any of several degrees of precision.
- Check out software provided for the course. Some of it may be useful to you.
- If you need something, ask me! Do you want to travel to see the client’s facility? Write me a proposal: How many people? Who? When? What is your itinerary? How much is it expected to cost? What will you accomplish?
What to do about errors in client data
You will encounter errors in the client data. Here is how to handle them: Answer the following questions as succinctly and clearly as you can.
- How big is the problem? If it affects only 10 skus out of 10,000, you can probably ignore it. If it affects 3,000, you cannot. If 1,000, then it depends.
- How will the problem affect your project? Does this problem completely stop the project? Does it threaten the time-line of the project? Can it be dealt with separately (for example, if the data problems were mostly with product in one zone of the warehouse)? Will this data invalidate your study or make it less accurate? How much less accurate?
- What do you propose to do about the problem? Avoid making work for your client. Your job is to figure out how to can get what you need with as little inconvenience as possible to the client.
In preparing the problem statement be clear and as brief as possible. Try to present the problem so that the client can understand it at a glance. Make it easy for him to choose one of the suggested options for how to proceed. For example:
- Some skus have a dimension (length, width, or height) of 0.
- 1,438 out of 25,000 skus
- The attached table shows the 50 most important skus of those with missing dimensions.
- How this will affect the project
- We cannot reliably slot these skus because we do not know how much space each occupies.
- Proposed remedies
- Alternative 1: We visit either the warehouse or a retail store and measure the 100 skus that matter most. We ignore the rest (as in Alternative 3).
- Alternative 2: We estimate the sizes of the most important skus based on text descriptions.
- Alternative 3: Based on current sku densities we estimate that 20 sections of shelving are required to hold the skus with missing dimensions. We suggest reserving this shelving so that these skus can be slotted after their dimensions are known.
How to use the data
Use part of the data to guide your design but reserve some of the more recent data for testing. (If you use the entire dataset for design and then use it again to test that design, you are in effect assuming perfect foreknowledge of the future and so your projected improvements will be unreasonably optimistic.)