6/14/2015–Creativity @ work may be as important as creativity @ home.
The daily cycle of restaurant work makes it seem as though nothing long-term is achieved. In that environment, it’s open-execute-close-repeat. Each day is an individual bucket of results, loosely connected by timely training, periodic prep for corporate visits, or holiday-related activities. It gets repetitive if no progress is tracked over time. Every Wednesday it’s the same special, etc. But I forgot the good part of that work–not the only good part but the good part with respect to producing results: that is, it feels good to achieve results in a 5-hour shift. We may be measured each day individually, but we did measure each day. This is in stark contrast to my current environment @ a big company. Days are too small a point on the timeline to justify any valuable metric (at 1st glance–I may see a way to do it soon). This makes me feel like there’s no way to tell where I’ll end up at the end of a 3-month project. In a restaurant, daily sales reports make it obvious how the month is going. Here, it’s like entering a pitch-black tunnel with few windows. Really, the only way to know status is by speaking and listening.
Maybe that is the feedback method in this environment; it’s to ask a valid source how you’re doing. The metric is obvious in restaurants–sales, comps, growth. There it seems to be “how many people I’ve spoken to”, but that doesn’t necessarily mean results, nor would “good info gathered” since I’d have to apply it. Rather, the end-of-project deliverable must be stated in a way which can be broken down to a smallest-reasonable metric. This is the 2nd benefit of having “MT” (measured and time-bound) goals (the 1st benefit being clarity/objectivity); that is, increased chances of the future state being what was intended as informed adjustments are enabled along the way. Disintegrated projects are like tunnels with many windows. Each “smallest-reasonable metric” is a glimpse at the progress made–they must be clear and probably are more effective placed equidistant from each other, but more frequently at the beginning.
The struggle now is determining what the future state is in terms of a deliverable. Actually maybe the future state IS the deliverable… That only applies to some projects though. I am expected to deliver a future state of talent mgmt which allows for effective role–employee pairing. Conversely, another project of mine calls for the creation of a future state in which sites know what’s required to launch a specific program. The former is a perception shift (a step change) whereas the latter is a reality change, progressing as a manual is created. The former is much more difficult to disintegrate. It may be that “future-state” deliverables may start to disintegrate as the project progresses-e.g. if it’s learned that the intended future state requires me to create new materials, the development of those books/tools/etc. could disintegrate into tasks. However, by nature, “future state” projects are recognized by continued behavior (assumed ad infinitum). Thus, this “infinite behavior” desired can’t be “delivered”, technically. Does that mean “future-state” projects are just the communication of recommended behaviors? I’ll say yes, for now. Continuing, it makes sense the disintegration of this would include identifying “who does what by when” (in scope of the project).
I imagine two scenarios: 1) the future state of talent mgmt does not include a “who/what/when” recommendation and 2) one which does include it. I think results don’t exist outside of behavior (motivation, attitude, coaching aren’t results). And no change in results are possible w/out a change in behavior (your behavior, theirs, or nature’s). Therefore, not only is who/what/when required as an element of all future state deliverables I think it may be the only requirement…
Now, as I imagine the delivery of this, it may be helpful to upload a .ppt or .docx file to the company server for reference; but the recommendation is best in whichever media is most effective to the executors of the new behaviors. Granted, approvers are likely needed to sign-off on resource allocation, so that may be part of the task list leading up to who/what/when delivery. In the end, if a who/what/when is communicated, the future state project is complete. Even if no approval is requested beforehand, executors know how to get it (perhaps it’s part of who/what/when?). If no reference material is created for future teams, subsequent 1:1 training would pass on knowledge, as it did prior to intranets.
Putting projects into these two categories day 1 helps me to begin effectively (always a weakness of mine). If I’m either able to see it as a “future-state” or rather as a “past state” project, I know to progress using a “who/what/when model” or a “disintegrated model” of project mgmt. Again the former is perception shift (a step change), the latter is a reality shift (a progressive change). Former: “At some point, this is how we operate going forward.” Latter: “To move forward, we need to have done or created this.”
It’s very possible that a project requires both. It’s also likely I’m missing some insight and this system is incomplete. I’ll try it out…
QOTW: “There’s no surrogate for a handshake.”
?FNW–Does the who/what/when model help? Yes–as a concept but not an excel file (for some).
11/19/2017 review–This is helpful still. The main point I want to emphasize is that it helps me to begin working on a project well. If I run my current workplan through this analysis, it proves helpful. I currently have a project that requires me to clarify how a group of people will operate in the future. My role requires identifying their purpose, membership, success criteria, and operations. In light of this model, it’s clearly a “future-state” project that requires a who/what/when deliverable. I need to communicate who does what by when in order for this group to be effective in the future. If I do that, my project is complete, and a new project begins (to manage that group’s operations). Seeing these as separate projects is an important distinction, as is the startup’s search for a business model vs the execution of that business model once it’s proven viable.
Conversely, I have a different project to organize and run an event for new employees. This clearly falls into the “past-state project” category, which requires a disintegrated model. I must disintegrate this event into measurable and time-bound deliverables. In this case, the event will require identifying who does what by when, but that in itself isn’t the project, it only allows the event to happen. The project is to have run an event.