My name is Michiko.  I’ve been working in IT pretty much my whole career despite the fact that I have no formal training in  engineering or computer science.  I think there are a lot of ‘mes’ out there – people with degrees in things like English or Art History who are working in tech.

In my case the degree is in the somewhat obscure field of Conflict Analysis and Resolution which is all about understanding the systemic sources of conflict, and analysis the dynamic of conflict.  And then, of course, coming up with plans to change the system or shift the dynamic for the better.

And for a very long time I thought my degree was rather useless, except for knowing how to conduct brainstorming sessions, or how to facilitate dialogue as a neutral mediator.  That stuff came in handy sometimes.

Back to useless.  So after about 15 years of experience in a wide variety of firms; big corporate firms, medium size software companies, the public sector, I started to see traits that brought success or failure to those organizations through the systemic models I had been taught in grad school.

Then when I got my PMP in 2007, I started to marry up project method with practices, and that explained some success and some failure.  Then I started really trying to understand business process management, and that explained some success and some failure.  And now, I’m starting to look at culture, which is really full circle because a  Conflict Analysis approach stresses a cultural review as a starting point.

This blog is really about what leads to success and failure in software development, strictly from the perspective of a non-techy PM. As the CEO of Crowd Fusion Brian Alvey said when I started working for him, “We are Michiko’s petri dish”.    I’m looking holistically; is it business process, project management, culture, communications? And I’m looking not just at my own company but at others too and trying to find threads and hints and ‘Success Modes’ as Alistair Cockburn calls them, that you can grab and use in your context.

Some readers know that I had a fairly successful blog ‘Preventing Project Failure’ devoted to a similar idea in the Project Management space.  It’s time for me to broaden that out and include Project Management’s siblings, Business Process and Culture.

By the way – those posts are all still here.

So enjoy…participate..engage…argue with me. Let’s together figure out what works and what doesn’t.

Last thing, shout outs are due. First to my mom, Margaret Singleton, who wrote the book Automating Code and Documentation Management back in the eighties.  I never read that book until I was deep into blogging and then was like ‘OMG – mom was talking about the same things  back then!’  Nature +1.   Finally, to my fabulous kids, Somala and Assoumou, who constantly get dissed with ‘Shut up! I’m blogging’ and still continue to love me.


5 thoughts on “About

  1. Good evening and hello, Michiko
    I have read your great article “Go with the flow” in the latest PM Network magazin about Kanban in Software development. the assembly line solution is very straight forward, also the transparency and visibilty approach.
    Well there are still some questions in my mind about
    the implementation of the processes.
    How did you get the support of senor management?
    What was the time frame for the implementation?
    Did you got support or the opposite from middle management?
    Thanks for sharing your thoughts with me in advance

    best regards

    Kayo Dittmar

  2. Hi Kayo,

    Thanks for stopping by and for your feedback on the article.

    I was very fortunate that senior management at my company really wanted to the Kanban system. The main driver was the distributed nature of the team and extremely short development timelines required by our customers. The company is small, so there really isn’t any middle management.

    So we needed something that anyone around the world could use right away, and could understand right away, and start work, as quickly as possible.

    Also – when I came into the company they were in a period of rapid expansion and Kanban was the first methodology they employed, and worked with the existing SVN and ticketing system (Assembla), so there were no real technological or legacy hurdles to overcome.

    The combination of executive support, a technological infrastructure that supported the method, and pressing business deadlines meant that there were few hurdles and implementation was rapid.

    I hope I’ve answered your question.

    Thanks again for your comment!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s