How I Work: Managing Projects from the Moon

It might as well be the moon, anyway! I’ve worked for MSIS on the other side of the Earth, nearly 8000 miles away from Ann Arbor, for just shy of seven years now. My day is your night, so we work almost completely opposite schedules, and I have only four overlap hours each week where we could have real-time exchanges. Like many of you, however, managing projects is one aspect of my job, and - in the spirit of teaching and learning from each other - I thought I’d give you a flavor for how I approach it. Some of this has been influenced by me being a teleworker, but most of it is just my own personal style, and I’m hoping you find all of it applicable to you. If you think I should be doing something differently, though, or if you want to ask me a question about my approach, please leave a comment below and we’ll stir up some conversation.

Manage a Team of One

Before I define work for others, I need to be able to define it for myself...

1. Self-start, understand what I need to achieve, set my own goals, and see them to completion. Don’t wait for someone else to spoon-feed me.
2. Spend some time planning each Monday so that the week is filled with meaningful activities. Sketch out more project stories than I think I can handle just in case I surprise myself (the same goes for any stories I sketch for others). If I have ticket work, know which ones I need to stay on top of. Prep some career development tasks to move forward on in the event that I find myself with a free moment without story or ticket work.
3. If I ever find myself procrastinating, bored, or hiding from particular work, I’ll talk to my Product Owner and/or supervisor about it. It could be a sign that the work isn’t actually worth doing or it isn’t yet defined well enough.

Spice Up Inception

When I start a project and whip up an Inception Deck, I tend to make these enhancements...

1. Help bring my project to life by including extra slides of prototype logos, potential product names, or imaginary ads.
2. Put images of people’s faces, not their names, on the stakeholder map. It personalizes the map, allows me to arrange the stakeholders on it more quickly, and helps me remember who’s on it.
3. When I reach the end of the deck, before I pick a t-shirt size, I write story candidates for the entire project. I make the stories as small (fewer points) and discrete (fewer key results / acceptance criteria) as I can, group them into iterations, then tally the iteration story points. I end up with a better t-shirt size estimate and I’m able to use those stories to get my project rolling as soon as it is cleared for takeoff. (I don’t stick rigidly to them, though - projects need to adapt as work unfolds - so I evaluate story candidates each week and add, modify, or delete as necessary.)
4. If the project feels too big, I add a slide to propose ways of breaking it up.

Stay in Touch

As my project marches onward, I keep connected to involved and interested people...

1. Find my audience at the beginning of the project by writing to customers and staff about what I’m doing and seeing who’s interested.
2. Mine my audience for feedback with interviews and surveys, then share the results with them so they know their input mattered.
3. When I need to get the word out about something, like a product I’ve launched or a survey I want people to participate in, I use a diverse array of media outlets: printed posters, digital signs, MSIS website carousel images, and newsletters like NCRC Community News and Announcements. Michael Warden, Susan Topol, and the MSIS Communications Committee are all great resources for ideas on this.
4. Update my Product Owner every day with a brief list of the project team’s progress on current stories. That gives them a sense the project’s momentum, allows them to make quick course corrections, and lets them give accurate status updates to anyone who asks. I do this through an Asana task that my Product Owner follows, but an email would do just fine.
5. Provide weekly progress updates to my “engage closely” stakeholders. I like to do this with a light presentation - just 3 or 4 slides - that covers what we completed in the week and what’s next on the horizon.
6. Ask my “keep informed” and “check with periodically” stakeholders how frequently they would like to receive progress updates (at weekly, every-other-week, or monthly intervals) and provide those updates accordingly (also through a light presentation).
7. Whenever a project artifact is drafted (design document, policy, process, learning materials, etc), or new piece of technology implemented, I invite my whole project team to review it and provide feedback.
8. Involve all the members of my project team in my weekly planning. Make sure they are available to work on the stories I assign and make sure they have a chance to influence them.
9. If I need to talk to someone in-person, but I’m pressed for time or separated from them physically, I ask someone to be my legs. I could ask fellow teammate Monica, for example, to help me ask a question at a morning stand-up.
10. Look for people who are involved in similar initiatives around campus or more broadly in the industry, then reach out to them for a fresh perspective, to learn from their experience, or to find new avenues of collaboration. Procurement has helped me do this, for example, by recommending people to talk to based on RFI/RFQ/RFP submissions and responses.
11. What I don’t often do are project meetings, be they in-person or via teleconference. I believe they often produce less value than the time they consume, so I use them sparingly and only when I feel there is no adequate alternative.

Make Myself Laugh

I consciously look for opportunities to inject fun and humor into my project wherever I can. It helps me stay motivated, leads to increased creativity in my work, and hopefully sparks interest in others. For example…

1. I build my inception deck and stakeholder updates around a theme and sprinkle in chuckle-worthy images, videos, and/or language. Project named ‘Jolly Roger’? I’m definitely putting a reference to scurvy in there. Everyone likes scurvy!
2. I announce product releases, at least internally to MSIS, with comic strips, animated GIF sequences, or similarly whimsical publications.

Make Things Better

With each project I manage, I try to...

1. Do something better than I did it the last time
2. Do something better than MSIS currently does it
3. Do something that MSIS hasn’t done before
4. Do something that creates value right now (not just at the end of the project)
5. Teach someone how to do something
6. Improve someone’s life, either as a result of the work or simply by the way I treat them in our interactions

So there you have it - examples of the way I work in one aspect of my job. But how about you? Do you do something a little bit differently from others around you? Do you think someone could benefit from knowing? Write a blog post and tell us about it. We're ready and we're hungry.

BISON - Building Information Summary - Ongoing (for the customer)

I finished my first project since moving into the Solution Center as a Product Manager in the PAM group. I would like to tell you about my experience with it.

As many of you know I worked on space information systems for many of my years at MSIS. This project brought me back to my roots.

Owners

As the first step to the BISON project, I met with the product owners, Mary Tresh from NCRC Facilities and Horace Bomar from Medical School facilities, along with Julie Walsh and Dan Duckworth.  I learned that their request was related to the desire to do strategic planning and analysis for all of the Medical School buildings.  Up to now, space information was presented by room, department or principal investigator.  In order to do building planning, it was necessary to redo some of the metrics for a building.

Inception Deck

After this meeting, I began working on the inception deck.  It was decided that this project be a small t-shirt size (4-6 iterations).   The customers were interested in learning about the inception deck. They were included in three rounds of updates.  Both the process and the t-shirt size proved helpful for them.  The customers identified what was most important for them.  The constraint on size eliminated requests that fit more of a "it would be nice to have someday" category.

MSIS wanted this project to stand alone after its completion so that it did not require continual maintenance.  To satisfy that, I took advantage of the skills that exist in the Office of Space Management.  Scott Williams, who is in that office, was put on the project as a programmer.  With a degree in electrical engineering, Scott has programming experience and was very happy to write programs for BISON.  He continues to monitor the monthly refreshes.

Pair Programming

Scott and I worked together.  Paring with Scott was very helpful since his insights in space proved to be invaluable in developing the product.  We had many discussions about how to best accomplish the goals before we started programming.  Scott was often on the keyboards since he was learning how to program in PL/SQL.

Product

The result of this collaboration is a set of tables that can be refreshed by the customer on a monthly basis.  Tables provide the following information:

• Building Productivity, $ of Indirect Cost / Research Square Footage
• Building Square Footage by Room Type, Lab, Lab Services and Office
• Building Station Count and Headcount
• Building Research Capacity and In Use Percent - number of average researcher would fit in a building.

Space requirements for an average Lab PI vs Office PI were defined; 1,300 sq ft vs. 300 sq ft.

Conclusion

The tools used in the process help define the project and move it to completion.  The customer's especially liked the inception deck and the agile methodology.  We would meet each week to plan out the work.  This kept us focused and the customers well informed as to the product that was being built.

Bennett Stallone

Winds of Change - Part 4: Lean BPM

by Tom Bellinson

Well, it's finally time to put this series out of its misery.  I'd like to thank both of my readers (especially you, mom).  I realize that this is just riveting stuff and you've been on the edge of your seat to see how it all ends.

I'm sorry to report that it never does end (this series does, but not the journey).  If there is one takeaway from these four posts it is to keep trying.  I once read a quote that said something to the effect that you cannot fail until you quit (that person never took a timed test).  Both BPM and Lean are about identifying areas for improvement and trying new things in a never-ending journey.

Whereas lean practices don't have a lot to say about how to identify areas for improvement, BPM fills that void by prescribing a very specific approach to analyzing processes to look for non-value added activities and exception handling.  Process maps provide a great way to illustrate these things.  Further, if you happen to have a complete set of process maps, they can be used to trace exceptions back to their root cause, which may not be in the process in which they occur.

Both Lean and BPM talk of low-hanging fruit.  Lean focuses on things that are easy to fix, whereas BPM tries to put a value on the problem to identify if the effort to fix it is worth it.  I am fond of saying that it doesn't make sense to spend $5,000 fixing a $5 problem unless it happens a lot.  Hard core process practitioners will model processes with tools that allow them to be simulated.  When done properly, the cost of process exceptions can be calculated in labor and material expenses.  Process timing data can also be used to calculate how exceptions affect throughput.  So, if a value can be assigned to the output, productivity loss can also be calculated.

Whether you run the numbers or not, the tools can help provide better estimates of the impact of process issues.  This is where Lean principles kick in.  Using Kaizen events to remediate process issues, teams can systematically provide for process changes, team member education, and physical plant changes.

The good news is, there is always low hanging fruit.

The three charts above have a different scale, but the biggest problem stays...well...BIG!  So it is with the way we look at our problems in general.  The biggest ones are always big -- relatively speaking.  If you're starving, getting your next meal is a big problem.  If you're rich, not being able to order your car with gold-plated rims could cause a similar aching in your stomach.

So, four blog posts later, is there anything that you can take away from this and use?  I sure hope so.  Otherwise, this has been a terrible waste of bits.  There's so much to know about both BPM and Lean.  If you took anything away, I hope it is that BPM is a great way to identify and quantify areas for improvement and Lean is a great way to tackle and remediate them.

Do either of these disciplines/philosophies/frameworks (pick your term) provide the necessary motivation to do anything?  Nay!  That, my friends, must come from you.  It takes a lot of work to create a culture in which people feel free to fix the problems they see -- or even study them to determine if they should be fixed.  If indeed we do live in such an organization, the next move is yours!  You may now return to your regularly scheduled program...already in progress.

Getting it Done with a Technical Work Map and Coaching

The product application manager on the DBA team disclosed that there was an outage where a data loss occurred over a year ago which initiated a project to upgrade the hardware for this database's server. The project, which was expected to take 3 to 4 months, had stalled and been in-progress for a year. The status of the project was unknown, including what work had been done. It was a high priority for this migration to happen because another outage could happen at anytime and it was predicted that the data loss would be more significant.

The interim manager agreed this project was top priority for the DBA team and I was ready to help get a project plan in place with a "User Story Map" to get it moving along. The exercise was straightforward enough and the group seemed to understand when I walked them through how we would build it despite their not participating in previous story mapping sessions.

However trying to build a story map with a DBA, product application manager, data analyst, software developer  and no product owner yielded what I will refer to as a technical work map. Which for the project at hand made sense and they felt what developed was useful. Basically in the technical work map user activities were developer activities and user stories were developer stories or tasks. Colored dots were placed on the stories to show responsibility and coordination for the DBA's, PAM, data analysts and software development. Marks would be placed in the dots to identify if a story was in progress, done, or cancelled.

Continue reading this BlogSpot at http://curiousagility.blogspot.com/2014/11/getting-it-done-with-technical-work-map.html

 

Follow me on Twitter @_AprilJefferon