Driving positive engagement with PLUSSING

The battleground

Working on new product ideas with new teams can be invigorating. Who doesn't like ideation and brainstorming.

OK. Some of us don't. Particularly when the team hasn't yet gelled to create a purposeful, positive environment.

When you have a mix of those that are quiet and defensive, and those that loud and forceful, a session designed to create new ideas can turn into an attack for the strong willed and a killing field for the passive.


99u explains that @Pixar a team of animators, when faced with such scenarios introduced a game that leveraged the concept to keep feedback real and authentic, yet still accept the positive aspects of an new idea by expanding it.

Plussing

Conflict and debate is part of the daily at any design organization. Every day teams review work from day before.

Such debate has been found to be beneficial in improving the overall quality of the work- as any Apple customer can attest.

Research has shown that teams debated ideas generated on average 25% more ideas than other teams.


@Pixar the response to the potential negative impact of continual "shredding" is that each criticism must contain a new idea or suggestion for strengthening the original concept – it must contain a "Plus".


A result we should all consider when developing new Service Experiences or improving Service Capabilities.

For more insight, consider reading this great article
http://99u.com/articles/7224/Why-Fighting-For-Our-Ideas-Makes-Them-Better
 

Was this useful?

Let others know what you think.If you found this post useful or provocative, please help me share it through comments and encourage others to subscribe to the blog.

One size doesn't fit all for ITSM tools

Some organizations especially smaller ones — find  complete ITSM systems preferable. While others prefer a best of breed approach.

Today you even can have the same capabilities delivered in a SaaS model.


One thing is for sure - for ITSM tools one size no longer fits all, with variables such as

• Company size & IT spend
• Complexity & rate of change 
• Geographical spread of the company
• User distribution (field, HQ, etc.)

Maturity level makes a difference

Others at a different ITSM maturity level wish to accelerate the development of best practices and increase efficiency across groups. They look for more sophisticated solutions that implement best-practice processes across multiple IT disciplines based on IT Infrastructure Library guidelines.

An organization with a high maturity level  has established processes covering multiple service management disciplines, such as incident and problem management, change management, configuration management, and asset management. Typically they require an ITSM solution that integrated tools across disciplines and fosters close collaboration among the various IT groups involved. In addition, the higher maturity level require processes based on ITIL. 

IT intensity affects capabilities

I've noticed that the breadth and depth of ITSM requirements are not necessarily proportional to a company’s revenue or the number of employees. In retail and manufacturing companies, for example, employees often share work­ stations. In the financial industry some employees may have more than one workstation.

Other organizations are outsourcing part or all of their ITSM activities to exter­nal providers. This puts different responsibilities on the requester and fulfiller, but also adds additional requirements around measuring SLA performance and tracking exceptions.

Mobility not just a nice to have

Mobile access to notifications with pagers was once considered advanced. But with today's mobile field force, mobile access is becoming more important both for end users and for IT themselves.

The Bring Your Own Device policies that are taking hold in organizations starts to affect the mobile device management capabilities. And the always on nature of business operations makes access to Service Management functions anytime, anywhere a key consideration.

You need to Decide

Different size and maturity companies have different needs.

Determine your needs up front to ensure that the solution you select meets your current needs and future potential needs.

To future proof your investments look for different solutions to match maturity and scale needs, and flexibility in deployment options.

Was this useful?

If you found this post useful, please help me share it with others and encourage them to subscribe to the blog.

Watch out for the sneaky ways of Change

What does a Change really want?

I must admit I was stumped the other day, when a customer asked me that questions in frustration at their attempts to implement a Change process.

Of course, a Change doesn't really actually want anything , but it certainly give me pause for thought to reflect on what Change is really about. Logic that ITIL suggests we take for granted.

To try and answer this question some more I thought I would consider some of the attributes of Change.

Top hits - the best and worst of Change

First, Changes are equal opportunity. Just like email, anyone with the right address can submit one. Unlike an email system there is no spam filter or junk folder. But by comparison, Facebook behaves very differently.

Second, Changes are implemented in priority order. There is a time-based aspect of priority - typically a First In First Out (FIFO) process similar to Email. But care should be taken not just to implement the most recent Change request, so we should also consider an override mechanism allowing Changes to be prioritized based on business need - for example Critical, High, Medium and Low.

Third, requests for Change do not expire. This is quite different from timeline notifications such as Twitter, which assume that we won't read information that's no longer up to date. Unless the request has been cancelled, it should still be in the Backlog.

Fourth, Change requests provide a persistent record. This is very similar to an To Do list. All Changes should be logged. In this way, requests for Change should never get lost and will eventually get implemented once they reach the top of the queue.

The Lightning bolt of Change

The Change process should be considered a system. Much like an ERP system, we shouldn't allow ourselves to operate outside the system. Occasionally we have individuals who try to opt out, but it's a dangerous precedent to set if allowed.

Changes shouldn't be implemented unless Approved. Assuming the right Approvals are in place, allowing a Change to proceed without approval is risking unexpected outcomes- mostly undesirable.

Separating Notifications from Approvals should clearly distinguish who needs to know about a Change from the teams that may be affected by the Change. Getting this right will streamline the Approvals, whilst ensuring that everyone that needs to know is aware.

Providing Change templates should make it very easy to submit regular requests, such as for a new server or increased disk space.Making it easy to submit common requests will increase adoption. Change templates can include the minimum level of approval for the request - reducing overhead on common, low risk requests.

Improved Automation coverage is a a side benefit of Change templates. With Templates we can track accurately how many such requests are made, and more easily identify the best candidates for Automation.

Closing Changes properly should include details on how long the Change took and whether it was completed successfully.With complete coverage of all Change requests and accurate data about outcomes Reporting provides more insight on the quantity and quality of work - which can improve the relationship with customers and highlight the benefits of initiatives such as Automation.

Staying in Control

Hopefully, none of this is dramatic news. Every system has a way it wants us to work. Twitter wants us to Tweet where we are and what we're doing. Facebook wants us Post status updates and Like each other. And Email, unless we're very careful, becomes a To Do list.

But the business expects more from us than occasional Tweets and Likes. We need to work with our counterparts to ensure that we're constantly pruning and prioritizing Change requests and finding new ways to deliver them faster.

This requires us to make deliberate choices that support the outcome implement Changes in the most efficient manner, while minimizing the negative impact on customers when Changes are implemented.

Was this useful?

If you found this post useful, please help me share it with others and encourage them to subscribe to the blog.