Tag: jQuery

Blog

Le Projet de 20% est Mort, Vive le Projet de 20%

Posted on by jaywll

Traditional proclemations aside, you may have read an article or two earlier in the year saying that Google has killed it’s “20% time” policy.

If you’re unfamiliar and you don’t feel much like clicking the above link, 20% time is…

“…a well-known part of our philosophy here [at Google], enabling engineers to spend one day a week working on projects that aren’t necessarily in our job descriptions.”

It’s well publicised that 20% time has been a significant contributing factor in giving us some of the Google products that we know and love today, so I hope for that reason that these rumors aren’t true. Regardless of that though, 20% time does seem at odds with the way the modern world works.

I’ve blogged a couple of times about ROWE so I’ll do my best not to digress into a further soliloquy about its merits here, but suffice to say I don’t measure my work in terms of time anymore. Allotting 20% of my time to projects that aren’t necessarily in my job description would be nearly impossible for me – not necesarilly because my organization wouldn’t allow it, but because I don’t know that I could figure out what 20% of my time is.

I’ve never worked somewhere with a policy of 20% time similar to Google, but that’s irrelevant. ROWE offers me something much better. I’m essentially free to use my time however I wish as long as the work gets done, and for me “20% projects” are absolutely a part of that.

Just because these 20% projects (as I’ll keep referring to them) aren’t right out of my job description doesn’t mean they aren’t work related, but they do offer me the freedom to try new things without fear of failure, and that leads to some great innovation (it leads to some failures and dead ends too, but that’s the point – it doesn’t matter).

I plan to blog some more about the gritty technical details in the not too distant future, but I’ve recently built a dashboard web-app on top of SharePoint using jQuery and SPServices. People love it, and it’s greatly increased my stock at work over the last few days. If my boss had come to me and asked me in a formal setting to develop this I don’t know if I’d have touched it. If it were a formal project from the start we’d have had to get IT to build it for us, probably at great expense. I, by contrast, learned how to do this stuff as I went along, and when I started work on it I had no idea if I’d be able to bring things to a successful conclusion.

My hope for my organization as ROWE becomes more of a popularised concept and way of working is that it encourages and enables other people to try new things – filter out the noise, spend less time doing and more time thinking. It worked for me, and it can work for you too.

0
Blog

Technology, for Process’ Sake

Posted on by jaywll

On Monday, a new piece of technology will launch at work. It’s a tool I both designed and built, and I’m extremely proud of my work.

The tool itself is web-based. It lives on a SharePoint server, is written in HTML with a healthy dollop of jQuery and the SPServices library thrown in for good measure.

It took some effort to build it, and I think the approach is a good one because on the back-end it makes good use of SharePoint’s functionality, but the front-end is completely custom with in-line error checking and user interface customizations that go far beyond what could be accomplished with SharePoint alone.

But that has nothing to do with why I’m proud of my work.

I’m also not especially proud of the project management stuff I did to bring this all together. It’s not that it was bad work, but my tool ran the risk of butting heads with a six sigma project that somebody else was running. They were basing a certification on their work, so I agreed not to implement anything until they were done. I thought I’d sequenced my work correctly, but when their three week pilot turned into a seven month pilot, I had nothing to do but wait.

To understand why I’m proud, we need to step back a bit.

The tool I’ve developed replaces another tool that was previously in use. It was also web-based, and it was owned by our organization’s IT team. As best as I can tell it was introduced in 2002, and in the eleven years since it launched we’d noticed a few niggly errors. We had a list of changes we wanted but this was minor stuff, the tool was used only by a select group of staff, IT resources are a hot commodity, and this was basically a priority for nobody except me. It’s at that point I decided my approach would be to build a new tool myself, from scratch. By going to all that trouble though I was opening up a whole new world of opportunity, and why waste it by reinventing the wheel? I wanted a smarter approach. And I had one.

I gathered together a group of SMEs from the handful of teams that used the tool day in day out – the people that had their hands on it every day – and booked a full day in their calendars to go through a kaizen event. We spent the morning mapping current state processes on the wall, writing out steps on post-it notes as we went and sticking them up in the relevant places.

By the time our lunch arrived this was done, and what I already knew was now abundantly clear to everyone else in the room. Our process was built around the tool that IT had delivered to us, eleven years prior.

After lunch I ran through a five minute PowerPoint I’d put together about muda, and we began unceremoniously ripping post-its off the wall, eliminating wasteful steps from the process. By the time we were done we had a vastly simplified, lean process mapped out. The kaizen participants surprised me more than once, coming up with things I would never have thought of on my own, changing the order of steps to support their ideal workflow, and eliminating hand-offs that I had thought might be sacred cows.

The tool I’ve built is only subtly different from what I was envisioning before the kaizen, but those subtle differences add up to a huge impact, and that’s why I’m so proud of my work.

It would have been all too easy to skip the kaizen and work from the already documented, well established business processes we had in place. What we’d have ended up with is a tool that looked prettier than the one that came before it, functioned better, and supported our processes beautifully. I’m fairly sure everybody would have been pleased with the outcome, and nobody would have stopped to think about whether or not the business processes were right to begin with.

What we have instead is, I think, a game changer – at least within the scope in which the tool and processes operate. We have re-engineered, optimized, lean processes along with technology that supports them but doesn’t define them. Management are happy because we’ve eliminated waste they hadn’t realised was there, on a scale they hadn’t imagined. The staff are happy because they’re empowered. Not only do our new processes support that, eliminating hand-offs and re-work that were only included to begin with in order to check the output of a group of people who were already perfectly competent, but also because they now have processes and a piece of technology that were designed and defined for them, by them.

That’s why I do what I do, and that’s why I’m proud of my work.

0