Forums

Hello all,

I hope you can help me
In my new management role I've been requested to make a standard about the bug workflow of the company and I have to improve the reports.

This is a big company with different offices worldwide. Each office has its own bug workflow and its own reports. Basically it covers their needs, that's fine, but now I have to make an standard.

I was wondering which is the right way to do it.
I guess that I'll have to have meetings with different people in each site, see their needs and then make a standard. But I was wondering if you could give some advice. Also, usually people are afraid of changes so changing the way they work and the way they report will be a challenge and I'm not sure if all people will have the will to move to the standard model that I have to put in place.

Thanks for your wise advice

ccleveland's picture

Chapu,

It sounds like you have a great opportunity and challenge!

Much of my current job sounds a lot like what you're describing. A couple of years ago, we had many locations doing the same "work" in different ways. During reorganization, a new group was created to help coordinate and standardize the work across the sites. We've done some things the wrong way and the right way...but each site functions much more like others, reducing headcount, increasing flexibility, etc.

So what can help you?

The biggest lesson I've learned is that you need to get each locations [u]real[/u] commitment to creating a common standard. Unless you have [b][u]very[/u][/b] strong relationships with the people involved at each location, this usually means getting (and maintaining!) management commitment. Depending on how big a change this is, it's even something that may go on performance objectives.

The rest of it isn't necessarily easy...but if you have a team of people at each location dedicated to creating a standard, then the work is mostly laying out requirements, priorities, and getting it done.

One final caveat... take care [u]early[/u] in the process to watch for people who don't seem to be engaged in the discussions. This often means they won't be very "engaged" when it comes to implementing the new standard and will continue to do what their used to doing.

¡Buena suerte! Let us know how it goes as you work though this!!

CC

chapu's picture

gracias :wink: CC, Really the tasks you mentioned are similar to my future key duties. I totally agree that I would need support from everybody, otherwise I will lose my energy fighting ... i have also another question in another post. Probably you had also to champion the implementation of new tools/processes. DO you have any steps (MT style) about what to do and the right order to champion this implementation?

Thank you,

ccleveland's picture

Yikes! I can and will take a shot at an “MT-style” list; however, project management methods are taught in classes that span days and weeks. So please understand that there’s a lot that and should happen within each step. Input from others would be a [u]very[/u] good idea! (hint, hint…feedback and other perspectives are encouraged!)

That said, here are some keys to making an implementation successful:
1. Create a “charter” for the implementation. This [u]short[/u] document briefly explains what is to be done and [u]why[/u]. As it’s being creating changes are fine…once everyone has agreed, changes are not fine. Any change in your implementation requires a review of the implications and agreement of those who provided input in the first place. Take extra effort to get it right the first time and avoid changes!
2. Pull the team together. Best case (if you have budget and the project is big enough) get them in one site. Establish ground rules: how/when/what to communicate, general areas of responsibility, how to handle conflict. Build team members respect and trust in each other as best and fast as you can.
3. Plan the implementation. …in writing! Think about what it takes to be done and all the components/deliverables it takes to get there. When you know [u]what[/u] needs to get done, assign [u]who[/u] should do it and by [u]when[/u] (Horstman). The overall level of detail is up to you. However, even at a high-level view, you need to capture the “what/who/when” of all the deliverables.
4. Set aside some time to think about what can go wrong with the plan. … and write it down! This is a good opportunity to use the MT brainstorming technique. The key to understand is just because something can go wrong doesn’t mean you have do anything about it. Sometimes you may change your plan, other times you may have a contingency plan if/when that bad thing happens, and sometimes there’s nothing you would do differently if bad things do happen. Review the items to see what is a high risk or a low risk.

All that planning…all that preparation, and it’s not implemented yet? Why not?

5. Just do it. When the planning is done well…this step is [u]easy[/u].

6. Clean-up. Did you deliver step 1? Is whoever wanted this done happy? Archive project documents. (I frequently go back to old projects for info.) Great time for an M-T Hotwash. (While a post-implementation review is recommended in all project mgmt. methodologies I’ve seen…I’ve not been very good at getting everyone together for one. [b]However[/b], since listing to the Hotwash podcast (~1 month ago), I’m planning one as one of my current projects finishes up.)

Congratulations…you’re done.

Hmmm…this is a very long post. Chapu, I do hope you and others get value out of it. It’s a chance for me to give back a little for everything I’ve learned.

CC

chapu's picture

CC, thanks, you explained very very well. Thank you very much for writting a post so detailed. It's really appreciated. I like to learn for people and I think you are good so I'll keep you updated and occasionally and I'll ask you feedback. I hope that's ok with you.

Thank you and have a great weekend.

thaGUma's picture

Chapu, sounds like a great opportunity. I would encourage a lot of listening. CC already mentioned about preople not engaging in the process. Sometimes all it takes is to have one or two points from each of the sites and integrate into the end result. If staff can look at the new standard and see a part of themselves in it, then they may feel more open to implementation.
Thank them for their contribution. Draw their attention to the section that they have had most input in. Spread the glory around.
Most important: rule 8. The other way often works just fine - so don't be precious about anything.

Have fun

Chris