Knowledge Genes®

What to do if you get Laid-off - How to Exit your Job Gracefully

Regardless of economic conditions, if you're laid-off, it's likely to feel personal and your emotions will probably fluctuate between uncomfortable and devastated. In a recent article for CBS, Katherine Cowley, a New York psychiatrist commented - “We like to deny that we are expendable. So when we are told ‘we have to let you go,’ it feels like an assault.”   

If you find yourself in this situation, try not to freak-out and remember that it's how you conduct yourself at this point that will either help you back on your feet or crash your career further into the ground.

Katherine Cowley also commented - "You never know who you will meet or need a reference from again. Exiting gracefully is one of the most important skills for someone who plans on building their career.”  

Here are the top 7 rules:

1. Don't freak out

Avoid showing anger or tears - they will not serve you well.  

2. Negotiate your exit

Turn the situation around - this is a very vulnerable moment for the person who's laying you off. Take advantage of that. Ask for letters of reference, moving costs etc...

3. Fine-tune your 'do do' list

Make some time for yourself - prioritize what work really needs to be done and work to get that completed.

4. Save your contacts

Download your address book and get contacts for your x-colleagues

5. Look after yourself

You don't want to turn up to interviews looking like a wounded animal so get enough sleep, food and some exercise. Also, try to enjoy your time out - do stuff you wouldn't usually have time to do like spending more time with your family and friends.

6. Reach-out to your networking circle

Be sure though to convey the right image. For example, make sure you'd be happy showing your Facebook page to your new boss

7. Drink responsibly

Amusing as it sounds, the last thing you want is to leave the wrong lasting impression with your x-colleagues of you drunk as a skunk at the leaving do.

For more information and more ideas on how to get the best from this situation, click here: How to Exit your Job Gracefully 

7 Simple Steps to Dominate Your Niche ...

Breaking into a new market, let alone dominating it is a challenge - to say the least.

The good news is that today, more than ever before, there's a whole bunch of powerful Web based tools that can bring this goal to life faster and more cost effectively than ever before. But, make no mistake - this will take considerable effort, time and commitment.

The 'secret' is honest engagement and quality content. If this sounds rather too simplistic, let me re-state - this will take considerable effort, time and commitment.

I've built a 7-Step Model of simple things you can do today to get started on this mission - click here to get the ball rolling

If there's any other 'killer' strategies not mentioned in this model, let me know and I'll make the addition.

Implementing Change Powerfully & Successfully ~ Kotter's 8-Step Change Model

Whether you're looking to make a small process change or a full-scale organizational change, it's common & quite natural to feel rather daunted by the challenge ahead of you. You know change needs to happen, but where to start? Who to involve? And so on ...

There are many theories around about how to successfully implement change and many of these are derived from John Kotter's (Harvard professor) 8-Step Change Model.

Here's an overview and some suggestions on how you can apply the 8 steps in your organization (for a quick to absorb model on this, please click here):

Step 1 Create a sense of urgency

For the change to happen, it needs the whole organization behind it - believing in it:

• Identify potential threats and develop potential scenarios showing what could happen in the future
• Examine the opportunities that should be exploited
• Start discussions, giving people convincing reasons to start thinking and talking and thinking about the change
• Rally support from your customers and outside investors to reinforce your argument

Step 2 Form a change coalition

To help convince people that change needs to happen, find and fuel effective leaders in your organization:

• Identify true leaders in your organization
• Ask for emotional commitment from these people
• Check your team for weaknesses and make sure you have a good mix of people from different areas and levels

Step 3 Create a vision for change

You need a clear vision so people can understand the purpose of what you're asking them to do:

• Determine the values that are central to the change
• Develop a short summary that captures what you see as the future of the organization
• Create a strategy to execute the vision
• Practice your vision speech often

Step 4 Communicate the vision

What you do with your vision will determine whether you are successful or not and you'll find many other run of the day company communications competing against yours:

• At every opportunity, talk about your change vision
• Address people's concerns - and there will be concerns
• Tie your vision to operations- training, reviews, hiring process ...
• Lead by example

Step 5 Remove obstacles

You need to remove obstacles to empower people to execute your vision:

• Identify change leaders
• Recognize and reward people for making change happen
• Identify those resisiting change and help them see the need
• Remove barriers - human and other

Step 6 Create short-term wins

Success motivates - give your team a taste for success:

• Pick a simple project you can implement with help from the die hard critics
• Choose inexpensive projects where you can justify the spend
• Reward the people the help you meet the goals

Step 7 Build on the change

Real change runs deep - keep looking for improvements:

• After every win, analyze what went right and what went wrong
• Set goals to continue building on what you've achieved
• Learn about Kaizen

Step 8 Anchor the changes in corporate culture

Make the change stick!

• Talk about progress every chance you get
• Tell success stories
• Include values when hiring or training staff
• As key leaders of the change move on, be sure to replace them

To see the Knowledge Gene on this, click here - Kotter's 8-Step Change Model

How to Guarantee Project Failure

Project failure is far easier to come by than project success unfortunately. Today's post is meant mainly for fun in our serious world - or perhaps it's closer to the bone than that. The truth is, there's probably aspects of the below six points that most of us can relate to in one way or another, right? By the way, just to be clear, this isn't an endorsement of these - it's just an observation. 

This list isn't exhaustive, but as a starter, adhere to these and you're well on the way to project failure:

1. Whip your team to higher performance
2. Save time, execute your project in one big step
3. Don't waste time on 'obvious' communications
4. Don't worry about all that 'unnecessary' planning
5. Know that all you really need is good old common sense
6. Satisfy your clients, no matter what, however 'ridiculous' the request might be

Is there anything missing in your experience? I'd be interested to capture your experiences in this area.

For more information and to see the Knowledge Gene on this, click the link below:

How to Guarantee Project Failure 

How to use a Stakeholder Requests List as Part of Scope Definition

I recently read an article by Laura Brandenburg, an experienced Business Analyst Consultant - which outlines a great idea she has on how to effectively use a structured stakeholder requests list for defining scope, fleshing out requirements - and ultimately to control scope creep.

In summary, the idea looks like this:

1. Put together all competing stakeholder requests

• list out all the requirements you've received
• capture these in a simple excel spreadsheet

2. Then, evaluate each request

• determine if it is a business need
• determine if it is a requirement
• determine if it is a detailed or a high-level requirement

3. Then, begin to look at the requests as a whole

• determine if any requests relate to one another
• group requests together

4. Help stakeholders decide which items are in scope for the project and which are not in scope

• first, list out the business benefits for each item - consider organizational fit, cost of implementation, which systems are impacted ...
• identify items which have multiple requestors and consider these as potentially high priority items
• then, articulate this list as a brief category or a perhaps a full benefits statement, depending on the circumstance

For more information and a roadmap on this, click the link below:

How to use a Stakeholder Requests List as Part of Scope Definition

How to Successfully Closeout a Project

Successful project closeout is critical, yet for one reason or another, it's an area that's often left loose at the ends - with the potential for disastrous consequences for sure.

Project Managers who 'tie the ends', properly closing-out projects create significant benefits for themselves, their organization and for others. These benefits include better success for future projects, better employee motivation, better customer relations, improved attractiveness to repeat and new business ... But, proper project closeout isn't a nice to have, it's a critical process step.

The process includes:

Verify Scope:

- Review all test data against the approved specification
- Identify & resolve any discrepancies
- Validate all supporting documents
- Verify all deliverables are available
- Assess customer satisfaction

Closeout Contracts

- Ensure that all open issues are resolved with the customer
- Return or destroy all customer's proprietary documents at the customer's direction
- Help the customer conduct an audit of completed scope
- When the customer is happy, receive final payments

Closeout Administration

- Return all personnel loaned to project
- Complete personnel performance evaluations

Conduct a Lessons Learned Review

- Conduct a survey
- Hold the lessons learned meeting

Build a Project History File

- Document planned & actual schedule duration and include data on past similar completed projects
- Document planned & actual labor costs and include past data
- Document all approved changes to PM plan
- Document all meetings minutes
- Document all problems
- Document subcontractor performance records
- Document customer satisfaction records
- Document project reviews

Create the Final Project report

- Describe the overall success of the project
- Describe organization on the project
- Describe recommended changes for other similar projects
- Describe techniques used to get results
- Describe project strengths & weaknesses
- Describe project team recommendations

Celebrate Success

- Involve everyone on the project
- Gather outside the working environment
- Recognize outstanding performers
- Express appreciation to all project participants

For more information and a quick-to-absorb roadmap on this, please click below:

How to Successfully Closeout a Project

How to Successfully Conduct Stakeholder Interviews

A simple, semi-structured stakeholder interview is a very rich & valuable source of insights. They are a highly effective way to understand areas of misalignment, understand stakeholder expectations & priorities, as well as strengthen relations and install confidence. However, particularly for newbie's and new organizations, these can be a daunting and nerve-wracking experience.

So, how should you optimally conduct stakeholder interviews?

Allow yourself plenty of time

• set aside at least 45 minutes for each interview
• leave at least 30 minutes between each interview to make additional notes and to clear your head before the next interview

Be prepared for your interviews

• have a pen that works!
• have a copy of the company's most recent annual report
• have any business research handy that the company has undertaken
• have a copy of the company's last major strategy / planning document
• have copies of print advertisements currently in circulation where applicable
• where they exist, have a copy of their mission statement
• have a copy of the company's organizational chart
• let interviewees know prior to the interview the discussion topics

Limit an interview to just 3 or 4 topics

• talk about culture, challenges and goals
• don't talk about features or solutions

Keep interviews informal, semi-structures and simple

Ask the most valuable questions - for example:

• What points of pain do we try to alleviate with this project?
• Who are the primary people / roles feeling this pain?
• Why does this problem exist?
• What need will this project fill?
• What would happen if we don't go through with this project?
• How would you define success for this project? ...

Effectively document outcomes

• combine information gleaned from information with responses to your questions
• use direct quotations to highlight important points
• highlight responses that do not support the documented strategy or brand value 

Why are stakeholder interviews important?

To understand areas of misalignment

To understand roles and responsibilities

To understand expectations and priorities

To strengthen relations and achieve support

For more information and a quick-to-absorb roadmap, click the link below:

How to Successfully Conduct Stakeholder Interviews - a Roadmap

What Does it Take to be a Successful Agile Project Manager?

In today's climate, project budgets are constantly being slashed and project managers are under ever-increasing pressure to deliver projects to customer expectations, on time and within budget. The effective manager must constantly adapt to changing conditions to successfully reach the finish line within the constraints of the project.

These conditions have fostered an increasing interest in agile due to the benefits it brings - fast delivery, flexibility, high quality and reduced risk. A key characteristic of agile PM vs. traditional methodologies is the intense collaboration, communication and enablement of supported self-organizing teams.

I've assembled some key characteristics that make an Agile Project Manager effective:

Anatomy of an Agile Project Manager

Feel free to pile in with additions to these characteristics.

How to Design & Deliver Effective BPM Governance

BPM governance is critically important, yet it's an area where more clarity and simplicity would be helpful.

The ultimate goal of a successful BPM program is the proactive, efficient management and continuous improvement of the set of process (and their sub-processes) by which an organization delivers value to its customers and other stakeholders - there it is.

5 key elements to Business Process Management (BPM) governance are:

1. Measurement
2. Ownership
3. Accountability
4. Control
5. Support

This Knowledge Genes (below link) captures the key points on how to effectively design & deliver BPM governance as well as some 'deadly sins' to watch out for, else problems abound:

Design & Deliver Effective BPM Governance

Effectively Manage Scrum Projects ~ Principles & Best Practices

This article is based on a artcicle I found in Agile Journal, which I though was a good round up of Scrum key principles and best practices. The Knowledge Gene on this (bottom link) captures these key points in a quick to absorb model - for busy folk.

Scrum is a popular agile software development methodology. It's iterative, highly collaborative and an effective way of quickly delivering useful software while keeping true to quality. Unlike 'traditional' methods with their protracted processes and lengthy documentation, Scrum focuses on responding to emerging requirements.

The Key Principles are:

1. Collaboration and communication - face to face meetings, co-located teams or for geographically dispersed teams, extensive utilization of communication tools
2. Product backlog - smallest, workable pieces of functionality that translate into tangible business benefits. These items must be deliverable live in short iterations of 1-4 weeks. This backlog is then maintained to deliver against incremental iterations
3. Get to market faster - in other words, working software that's delivered in weeks
4. Stakeholder engagement - agile teams view stakeholders as important & visible members of the  team and engage them right from the start and throughout the project
5. Capacity management - every aspect of capacity is assessed and agreed before delivering any live software
6. Release planning meetings - planning and scheduling of design iterations is done up-front. Designers pick user stories from design backlog and produce low level solution designs. Then, teams will pick up the designed user story
7. Coordinated sign-offs - agile teams ensure sign-off at every stage of the software development lifecycle from relevant stakeholders
8. Risk management - the product owner actively monitors the software delivered and ensures that stakeholders give early visibility to managing risks and issues
9. Effective change management - agile teams are welcoming and responsive to changes that stakeholders require. Working with the stakeholders helps ensure that these changes are aligned to the business goals. Agreed changes should be planned and scheduled in retrospective Sprints
10. Effective control of budget and resources

Best Practices Include:

1. Optimize daily stand-up meetings (Scrums) - try to keep meetings to 15 minutes as a maximum and ensure that the whole team attends too. If a member is unable to attend, ensure that they update another attending team member. Start the meeting with the person that joined the meeting last and ensure that each individual clearly articulates answers to 3 key questions: What did I achieve yesterday? What will I achieve today? What impediments are blocking my progress?
2. Effectively use collaboration tools - to create documentation, share user stories and so on
3. Where practicable, co-locate teams (or for geographically dispersed teams, extensively use audio visual communication tools)
4. Integrate feedback and decision making - be sure to actively involve the stakeholders through the lifecycle. This will dramatically improve decision accuracy
5. Maximize article re-use - this will save you oodles of time
6. Optimize review and sign off meetings - at the end of each iteration, as a minimum, have a quick meeting to discuss what worked and what didn't and sign off deliverables. You can then effectively incorporate lessons learn into future iterations - continuously improving the process as you go.

The Knowledge Gene (below link) captures the key points above in a quick to absorb model - for busy folk:

Effectively Managing Scrum Projects ~ Key Principles & Best Practices

5 Scrum Transition Anti-Patterns

We're big fans of agile methodologies around here because of the clear benefits it brings - reduced risk, satisfied stakeholders, faster to market and so on and so on. But, to keep things in balance, agile isn't all peaches and roses. Like most things, it has its pitfalls - although these anti-patterns are far outweighed by the benefits in most agilistas experience.

So, I wanted to explore some of these anti-patterns that people might experience when transitioning to agile from another methodology and crucially, how to avoid them. In this instance, I explore common anti-patterns that people have experienced when transitioning to Scrum (later I'll check out anti-patterns specific to other specific methodologies).

These anti-patterns are based on experiences from a wide range of projects in Europe and Australia, quoted in an article by Rowan Bunnings, an Agile coach based in Australia.

These anti-patterns include:

1. Premature process optimization
2. Exceeding transition speed limit
3. Misaligned 'sashimi slicing'
4. Accumulation of undone work
5. Individual heroics

Click below to see the Knowledge Gene on these, how to avoid them and why it's important to do so:

5 Scrum Transition Anti-Patterns

Are there any other anti-patterns that you've experienced (I'd be happy to add these)?

How to Effectively Scale Agile Processes to Larger Teams

Many practitioners think that agile development is applicable onto to smaller teams because well known processes like Extreme Programming are often applied to project teams of 10 or fewer people. As it happens, 70% of all software development teams are this size. 

But, can agile processes be scaled to larger teams? Absolutely yes, according to Scott Ambler:

"Size is in the eye of the beholder - for some people a team of eight is huge; for others a team of 50 is small. A large project, for our purposes, is one that is 20 percent or more larger than what you're used to, although for the sake of this column, let's get specific: A team of 15 people or more will be considered large.

The good news? Agile methods have been successful with large teams. The first Feature Driven Development (FDD) project was 50 people, and the second 150. XP, in conjunction with Scrum, has been successfully used on teams of 50, and I've heard stories of teams of 100. In 2002, Ron Crocker developed an agile process called Grizzly at Motorola for a project team of more than 200 people. It's clear that agile scales." - Scott Ambler

This Knowledge Gene is my interpretation of Scott Ambler's writings on this topic:

Effectively Scaling Agile Processes to Larger Teams

The IT Infrastructure Library (ITIL) V3 ~ An Overview Model

The IT Infrastructure Library (ITIL) V3 series consists of five books providing guidance on the strategy, design, transition, operation and continual service improvement of quality IT services to support business needs. ITIL Service Lifecycle:

Needless to say, there's a heck of a lot to internalize, so I created a simple, easy to understand model (link below) that overviews the lifecycle: 

ITIL V.3 - Lifecycle Overview Model

Best Practices in Agile Estimating

Complex environments with frequent changes that cannot be anticipated require estimation efforts to be done in an incremental and adaptive way. It can no longer be done in a sophisticated, big-upfront approach at the beginning of the project. Agile approaches to estimation look simple, but they work.

Agile estimating best practices include:

1. Eliminate waste (don't estimate for it)
2. Decide as late as possible
3. Amplify learning and empower the team
4. Communicate constraints, not just numbers
5. Deliver as fast as possible
6. Optimize feedback and measurements

Click the link below to see the Knowledge Gene on these best practices - and how they're applied

Best Practices in Agile Estimating

13 Enterprise Modeling Anti-Patterns ~ How to Avoid Them

There are a fairly well known, amusing titled (but potentially disastrous) collection of Enterprise Modeling Anti Patterns that many professionals can find themselves falling into if they're not careful & smart about what they're doing. 

Based on an article by Scott Ambler, here's 13 of them:

1. "30,000 Feet and Climbing"
2. "Bleeding Edge"
3. "Detailed Enterprise Modeling"
4. "Gold Plating"
5. "Ivory Tower"
6. "Modeling for Modeling's Sake"
7. "Real World Disconnect"
8. "Strive for Perfection"
9. "Stuck in the Weeds"
10. "Technology Above All"
11. "Tomorrow Suffers From Today"
12. "Underground Future"
13. "Yesterday's Enterprise Model" 

Click the link below to see the Knowledge Gene on this & how these anti-patterns are avoided:

13 Enterprise Modeling Anti-Patterns

The Agile Manifesto ~ an Easy to Absorb Model of the Key Values & Principles

To address challenges faced by software developers, a small group of methodologists formed the Agile Software Development Alliance in 2001. This group defined a manifesto for encouraging better ways of developing software, and then based on that manifesto, formulated a collection of principles which defines the criteria for agile software development processes. The manifesto defines 4 values and 12 principles which form the foundation of the agile movement.

We coded these key values and principles in a simple model (below link) to make them easier to absorb:

The Agile Manifesto - Key Values & Principles

Business Process Re-Design (BPR) Best Practices ...

Business process redesign (BPR) is an important and complex discipline, and like many other things, pitfalls are easily encountered. For this reason, I thought it would be a useful exercise to collect together some best practices on this topics which have been asserted by respected thought leaders over the years - including Hammer & Champy, Klein, Peppard & Rowling, Berg, Pottejewijg, Rupp & Russell, Van der Aalst & Van Hee ...

These best practices are universal in that they are applicable in the context of any business process, regardless of the product or service delivered.

Of course, the list isn't all encompassing, so if there's a best practice that you use, that's not mentioned in this model, please do let me know and I'll be happy to include it ...

Click the link below to see these best practices, how they're applied & why they're important.

Business Process Re-Design (BPR) Best Practices - coded by M Ridgwell

10 Key Skills Architects Must Have to Deliver Business Value

What key skills must an architect have to deliver business value?

No question, there's confusion out there as to what an architect actually does, roles vary widely from one  organization to another and terminology over-complexity thrown in by leading analysts like Gartner tends to confuse the issue further. Some clarity would be nice me thinks ...

I found this nice article by Michael Rosen of the Cutter Consortium which, in IMHO, does a decent job of clarifying this. He discusses the role of the architects and describes 10 activities that architects should perform to add value to projects.

He asserts that regardless of role, we can start to see a common set of skills that architects must have, such as having a big-picture view, analytical approach, abstraction, conceptualization, and modeling. When we understand the unique skills of an architect, we can see how to use those skills to assist projects.  

This Knowledge Gene is my interpretation of the article - to make the key points faster to absorb:

10 Key Skills Architects Must Have to Deliver Business Value (Michael Rosen) - coded by Mark Ridgwell

How to Play Planning Poker - For Agile Estimating

One of the most challenging aspects of any software project is estimation.

Planning poker is an estimating technique used by many agile software development teams. Like many agile development techniques, Planning Poker is very simple but effective.

This Knowledge Gene is a step by step guide to 'playing a round' of planning poker. The collective intelligence of the team is far preferable to 1 person's estimate, right? 

How to Play Planning Poker for Agile Estimating

How to Implement Scrum in 10 Easy Steps ...

I recently found a good article by Kelly Waters on 'How to Implement Scrum in 10 Easy Steps'.

There's a whole bunch of 'noise', different approaches and terminology about 'agile' these days - which can paint a picture of complexity and confusion about the discipline which is at odds with the whole straightforward principle of 'agile'. The Scrum methodology, once you get passed some basic jargon like 'Sprints', Scrums / Stand-ups and all that is a simple, pragmatic method for effectively managing software development.

In his article, Kelly outlines 10 simple steps to implement Scrum:

1. Get your backlog in order

2. Estimate your product backlog

3. Plan Sprint requirements

4. Plan Sprint tasks

5. Create a collaborative workspace

6. 'Sprint' to achieve the Sprint goal

7. Stand up and be counted (Stand-up meetings)

8. Track progress with a daily burndown chart

9. Finish on schedule!

10. Review, reflect & repeat process

This Knowledge Gene is a road map of the article, which captures the key points in a way that's easy to understand and use: - How to Implement Scrum is 10 Simple Steps

Do you have Scrum delight or pain experiences? 

"Consultants borrow your watch to tell you the time ... "

"Consultants borrow your watch to tell you the time then they walk off with your watch"

So said Robert Townsend, a former CEO of Avis, in his no-nonsense observation on management sillyness - Up the Organization.

This is often interpreted as meaning that consultants will question you and your colleagues, capture your knowledge, and then not adequately document and share with you what they've learnt. Or that consultant’s do not themselves actually have useful knowledge to share. Or that if they do, they are going to be very careful about sharing their knowledge asset with you in a way that would reduce your dependence upon them.  And when it all goes wrong, who is it that gets blamed? You do, for not controlling them properly.

Many people believe that this problem is as relevant today as when Townsend made his widely accepted observation. And the catalogue of disasters and frustrations suggest this is so. But there are consultants out there who have overcome this problem, consultants who offer a high quality service and get used again and again because they have addressed this most fundamental of problems. How do these 'good consultants' do it?

First, if ’good consultants' have real knowledge to donate, then they externalise it in a way that stays with their client when they leave - the knowledge is codified. Second, if they don't have the knowledge themselves then they facilitate the client to externalise what they really know but can't easily verbalise - again the knowledge is codified. And if they are working on information systems, they make sure it's very clear WHAT needs to be done, HOW and WHY - again the knowledge is codified.

Knowledge Genes is the world's first successful attempt to codify knowledge and is now used successfully by consultants in some of the world's largest and most prestigious organizations. You no longer need to accept ineffective consultancy engagements. If they go wrong nowadays, maybe don't blame the consultant, maybe blame yourself.

And if you contact us, we can give you a list of consultants that can be relied upon to be 'good consultants' - they won't borrow your watch to tell you the time, and they won't walk off with your watch!

Best Practices for Engaging Stakeholders

Stakeholder engagement is critically important to project success, although like so many things, it's easier said than done. Through proactive communication, involvement and transparency, this should be a significant focus of your project effort from the outset through completion and beyond - else perils abound. 

You don't need to engage with all stakeholders with the same level of intensity. You need to be crystal clear on whom you need to engage with and why. This requires prioritizing your stakeholders and, depending on whom they are and what their interests in the project are, figuring out the best ways to engage them.

This Knowledge Gene is a guide to successfully engaging stakeholders, to help achieve project success:

Best Practices for Stakeholder Engagement - coded by M Ridgwell

Agile Project Management - A Risk Mitigation Strategy

Risk management is about identifying, addressing, and eliminating sources of risk before they become a serious threat to the project. A key differentiator between agile vs. 'traditional' methodologies is that agile focuses on deep collaboration, communication and team enablement, which means that project impediments are picked up and dealt with earlier. 

Agile project management reduces risk by directly addressing several main common risks including - scope creep, shortchanged quality, unrealistic (over-optimistic) schedules and poor developer / customer relations. It does though have its drawbacks though, such as the potential to increase the liklihood of inadequate design.

Overall though, agile reduces more risks than it introduces.

This Knowledge Gene takes a look at agile project management as a risk mitigation strategy, how it's applied and what benefits it brings:

Agile Project Management ~ a Risk Mitigation Strategy

Strategies for dealing with Agile Project Constraints

Business stakeholders regularly 'squeeze' teams with time, money or features constraints. And doing agile in these conditions can seem a difficult or impossible task. Actually, it is usually possible to work within these constraints and still be agile.

Project managers will be familiar with the 'iron triangle' concept, which states that of the three factors -resources (cost, budget), schedule (time) and scope (features, functionality), at least one must vary to maintain quality.

In an ideal world, all three factors will vary to give the best management flexibility, but in practice, it's rarely an ideal world. You team probably does face some constraints, but will still have room to maneuver if other key factors are not constrained. The worst case scenario of course is when all factors are constrained which gives the project little chance of success. In these conditions, at least one constraint needs to be freed-up, else you should consider ditching the project. 

This Knowledge Genes takes a high-level look at some of the strategies that you can adopt to successfully deliver projects and remain agile, should constraints be placed on you by business stakeholders:

Strategies for dealing with Agile Project Constraints

Is Sustainability the Key to Achieving Long Term Growth?

I recently stumbled across an interesting article "Innovating for the Future - Sustainability" by Harvard Business Publishing...

In the article, Eisenberger, Glantz, and Gottesmant assert that despite what we might expect; business leaders are starting to see that success in sustainability is key to emerging from the current recession and achieving long-term growth.

They go on to say that we won't get there solely through green marketing or through one-off initiatives like renewable energy purchases. Strategic leadership on sustainability will require understanding the key trends that could change the way your business runs and then innovating to capitalize on new opportunities or ways of doing business.

This Knowledge Gene captures the key points from the article:

Innovating for the Future - Sustainability (Eisenberger, Glantz, Gottesman) - coded by Ian Rainton

Best Practices for Agile Development Governance

The demand for IT governance is increasing at a rate faster than the capability to govern IT is maturing. While greater scrutiny on spending and increased business regulation ratchets up pressure, IT management struggles even to come to consensus on a definition of what governance is and is not. Governance initiatives are typically little more than bureaucratic "bolt-ons" to monitor employee activity.

"The goal of an IT governance program is to establish chains of responsibility, authority, and communication to empower people in support of the overall enterprise goals and strategy. You do this by balancing risk versus return on IT investments, setting in place effective processes and practices, defining the direction and goals for the department, and defining the roles which people play within and with the department. Development governance is an important subset of IT governance, the scope of which covers the steering of software and system development projects. The focus of this three-part article series is on practices which support lean development governance. 

Traditional governance often focuses on command-and-control strategies which strive to manage and direct development project teams in an explicit manner. Although this is a valid and effective strategy in some situations, for many organizations this approach is akin to herding cats -- you'll put a lot of work into the governance effort but achieve very little in practice. Lean governance focuses on collaborative strategies that strive to enable and motivate team members implicitly. For example, the traditional approach to coding guidelines would be to create them and then enforce their usage through formal inspections. The lean approach would be to write the guidelines collaboratively with your programmers, explain why it is important for everyone to adopt the guidelines, and then provide tooling and support to make it as easy as possible for developers to follow those guidelines. This lean governance approach is akin to leading cats; if you grab a piece of raw fish, cats will follow you wherever you want to go." - Per Kroll, Scott Ambler 

Best Practices for Agile Development Governance (Kroll & Ambler) - coded by M Ridgwell

Best Practices for Agile Project Planning

Effective planning is critical to project success, but it can be a highly complex task, prone to error and rarely approach by people with fondness. Many people these days are adopting agile planning approach for the benefits it brings such as reduced risk, better governance, stakeholder buy-in, to name only a few.

A fundamental difference between agile and traditional project planning is that agile project planning is highly collaborative in nature and the team takes responsibility for the planning, not just the project manager.

Agile adoption seems to be on the up too. A 2008 survey included the following results:

1. 69% of respondents indicated that their organizations are doing one or more agile projects. And of those that hadn't yet started, 15% believed that they would start within the next year.
2. 82% of organizations doing agile were beyond the pilot phase.
3. Respondents overwhelmingly indicated that agile teams are producing higher quality, higher productivity and better stakeholder satisfaction.

Based on an article by Scott Ambler, this Knowledge Gene (bottom link) is my interpretation of the key points the author asserts - to make the material easier to absorb and use:

Best Practices in Agile Planning - coded by Mark Ridgwell

Conflict Resolution Management ~ Best Practices

Conflict is all around us in work and in life and it's not necessarily a bad thing. If approached with calm, respect and understanding, successful conflict resolution can have some very positive outcomes such as better team effectiveness, improved staff retention, increased understanding and personal development. 

Different people with different goals come into conflict, its human nature, but too often the result is bad feeling, tension and personal animosity. This is a very damaging situation that's generally (not always) avoidable. 

The fact is that most people just don't handle disputes well. It's not that they're not potentially good at it, but more likely, they fail to set the scene, clarify personal needs and most importantly, they fail to understand things from the other person's perspective.

This Knowledge Gene is a collection of quick to absorb, easy to use conflict resolution best practices - useful where you have an interest in seeking a negotiated solution.

These steps don't guarantee success but they will greatly improve the likelihood of successful conflict resolution outcome, in a calm and respectful manner that reduces the impact of stress, fears and "surprise" factors involved in dealing with conflict.

Conflict Resolution Management Best Practices - coded by M Ridgwell

7 Habits of Highly Effective People ...

"Your life doesn't just "happen." Whether you know it or not, it is carefully designed by you. The choices, after all, are yours. You choose happiness. you choose sadness. you choose decisiveness. You choose ambivalence. You choose success. You choose failure. You choose courage. You choose fear. Just remember that every moment, every situation, provides a new choice. And in doing so, it gives you a perfect opportunity to do things differently to produce more positive results." - Stephen Covey

I've recently finished reading Stephen Covey's fantastic "7 Habits of Highly Effective People". This is good stuff and not the collection of clichés I'd half-expected. It's caused me, just a bit, for now, to put my lot in perspective - which I probably needed.

If you haven't read this little gem, I'd recommend that you do so and if you simply don't have time, check- out this Knowledge Gene instead which captures the high level key points.

"7 Habits of Highly Effective People" (Stephen Covey) - coded by M Ridgwell

Best Practices for Agile Documentation

In keeping with my all-things-agile fixation, I recently read another excellent article by Scott Ambler - Best Practices for Agile Documentation. Scott is a widely regarded, Canadian based software architect, 'agilist' and author, amongst other things.

"Ideally, an agile document is just barely enough, or just barely sufficient, for the situation at hand.  Documentation is an important part of agile software development projects, but unlike traditionalists who often see documentation as a risk reduction strategy, agilists typically see documentation as a strategy which increases overall project risk and therefore strive to be as efficient as possible when it comes to documentation. Agilists write documentation when that's the best way to achieve the relevant goals, but there often proves to be better ways to achieve those goals than writing static documentation." - Scott Ambler

Scott's article is pragmatic, experienced based and very much with the customer in mind, although there's a lot to internalize for uber busy sorts who seek a quick-fix. So, I've created a model which captures the key points, how they're applied and why - to make the material faster to absorb and use.

Best Practices for Agile Documentation (Scott Ambler) - coded by M Ridgwell

Project Management Best Practices (& common sense) ...

Projects screw-up all the time. Organizations search hard for the key to unlocking the 'mystery' of project management success, but the steps to successfully delivering projects is no mystery at all — just standard, common sense procedures that if executed right will dramatically improve a project’s chances of success. Projects fail because of poor planning, fuzzy requirements and ineffective communications - period. 

I've created a Knowledge Gene of PM best practices, to make the key steps easier to absorb & execute.

Project Management Best Practices - coded by M P Ridgwell

Is there anything missed, in your view? 

Gartner identify 'emergent' architecture ...

Gartner recently proposed a new approach for enterprise architecture (EA) and they seem to have done a wonderful job at 'gunking-up' an already complex space with terminology complexity that's, frankly, confusing the living daylights out of people. Although most people do seem to agree that there's little radically new here.

I felt compelled to try de-gunking Gartner's emergent EA properties - to try to make some sense of them.

Gartner's proposed properties and a couple of reaction are below:

"1. Non-deterministic - In the past, enterprise architects applied centralised decision-making to design outcomes. Using emergent architecture, they instead must decentralise decision-making to enable innovation.

2. Autonomous actors - Enterprise architects can no longer control all aspects of architecture as they once did. They must now recognise the broader business ecosystem and devolve control to constituents.

3. Rule-bound actors - Where in the past enterprise architects provided detailed design specifications for all aspects of the EA, they must now define a minimal set of rules and enable choice.

4. Goal-oriented actors - Previously, the only goals that mattered were the corporate goals but this has now shifted to each constituent acting in their own best interests.

5. Local Influences: Actors are influenced by local interactions and limited information. Feedback within their sphere of communication alters the behaviour of individuals. No individual actor has data about all of an emergent system. EA must increasingly coordinate.

6. Dynamic or Adaptive Systems: The system (the individual actors as well as the environment) changes over time. EA must design emergent systems sense and respond to changes in their environment.

7. Resource-Constrained Environment: An environment of abundance does not enable emergence; rather, the scarcity of resources drives emergence."

A couple of reactions:

"Sounds a bit pretentious, to say the least. It looks a bit odd that Gartner had uncovered these best practices so late, after such a long time practicing and preaching EA" - Adrian Grigoriu

"I think they finally woke up to the facts of life about EA.  Their seven properties show that they are just now realizing that centralized, top-down, autocratic decision making does not work - Mike Rollings

I welcome your perceptions on this topic.

Jerk infested workplaces are common ...

The problem is more widespread than you might think. Research in the United Kingdom and the United States suggests that jerk-infested workplaces are common: a study by Loraleigh Keashly and Karen Jagatic found that 27 percent of the workers in a representative sample of 700 Michigan residents experienced mistreatment by someone in the workplace.

Companies that put up with jerks not only can have more difficulty recruiting and retaining the best and brightest talent but are also prone to higher client churn, damaged reputations, and diminished investor confidence. Innovation and creativity may suffer, and cooperation could be impaired, both within and outside the organization-no small matter in an increasingly networked world.

Lars Dalgaard is CEO and co-founder of SuccessFactors, one of the world's fastest-growing software companies. Dalgaard once listed some milestones that his California-based company passed in its first seven years:

• the use of its software by more than 2 million employees worldwide

• the use of its software by employees speaking 18 languages in 156 countries

• growth three times that of the company's nearest competitor

• enthusiastic recommendations of the product by nearly all customers

• dramatically lower employee turnover

• employing no jerks ...

That's right, no jerks, although the word Success Factors really uses (except on its Web site) is a mild obscenity that starts with the letter A and sort of rhymes with "castle." All the employee's SuccessFactors hires agree in writing to 14 "rules of engagement." Rule 14 starts out, "I will be a good person to work with-not territorial, not be a jerk." One of Dalgaard's founding principles is that "our organization will consist only of people who absolutely love what we do, with a white-hot passion. We will have utmost respect for the individual in a collaborative, egalitarian, and meritocratic environment-no blind copying, no politics, no parochialism, no silos, no games-just being good!" More on this at link below.

Based on case studies and my own experiences, I've build this Knowledge Gene as a quick to absorb roadmap to help you recognize and root-out jerks & bullies: 

Build the Civilized Workplace - by Ian Rainton

Agile Software Development ~ a people oriented methodology

 
Like it or not, Agile is all around us these days and according to Agile preachers like Scott Ambler, it has become mainstream. I'm sure he's right although I do wonder how many teams are really practicing agile.  

Agile Development minimizes risks by developing software in short amounts of time - in iterations that typically lasts from two to four weeks. Each iteration passes through a full software development cycle and a release - without bugs - available at the end of each iteration.

Agile Software Development is a conceptual framework for software development that promotes development iterations, open collaboration, and adaptability throughout the life-cycle of the project.

There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is referred to as an iteration (2-4 weeks). Each iteration passes through a full software development cycle, including planning, requirements analysis, design, writing unit tests, then coding until the unit tests pass and a working product is finally demonstrated to stakeholders. Documentation is no different than software design and coding. It, too, is produced as required by stakeholders. An iteration may not add enough functionality to warrant releasing the product to market, but the goal is to have an available release (without 'bugs') at the end of each iteration. At the end of each iteration, stakeholders re-evaluate project priorities with a view to optimizing their return on investment ...

Needless to say, it's totally inefficient trying to articulate this complex process further using text - so I created a model (below link) which makes the key points much easier to absorb:

Agile Software Development

Is "Just-Good-Enough" Good Enough?

There's been some interesting commentary going on recently about 'just good enough' and there seem to be many conflicting views about the effectiveness of this approach in practice. So, I wanted to explore this further, to try to tease out what 'good enough' really means to people, how it's applied and what benefits it brings.

This Knowledge Gene is a collection of views and experiences from discussions with practitioners as well as articles by Robert Capps (Wired), Scott Ambler and Brenda Michelson. I'm sure it's far from an exhaustive list and so I'd welcome your comments to further develop the model, based on your experiences.

What does just "good-enough" mean to you?

Straddling the Good-Enough Divide - coded by Mark Ridgwell  

Is there anything new in Gartner's 'emergent' EA?

The disconnect between IT and business is being crossed, amongst other things, by business users unafraid of today’s Web 2.0 technologies which foster collaborative working and better communication in the workplace and by a 'new breed' of IT folks with a strong desire to get involved in the business issues.

Gartner identifies 7 properties that differentiate emergent architecture from the traditional approach to EA:

1. Non-deterministic - In the past, enterprise architects applied centralised decision-making to design outcomes. Using emergent architecture, they instead must decentralise decision-making to enable innovation.

2. Autonomous actors - Enterprise architects can no longer control all aspects of architecture as they once did. They must now recognise the broader business ecosystem and devolve control to constituents.

3. Rule-bound actors - Where in the past enterprise architects provided detailed design specifications for all aspects of the EA, they must now define a minimal set of rules and enable choice.

4. Goal-oriented actors - Previously, the only goals that mattered were the corporate goals but this has now shifted to each constituent acting in their own best interests.

5. Local Influences: Actors are influenced by local interactions and limited information. Feedback within their sphere of communication alters the behaviour of individuals. No individual actor has data about all of an emergent system. EA must increasingly coordinate.

6. Dynamic or Adaptive Systems: The system (the individual actors as well as the environment) changes over time. EA must design emergent systems sense and respond to changes in their environment.

7. Resource-Constrained Environment: An environment of abundance does not enable emergence; rather, the scarcity of resources drives emergence.

“The traditional top-down style worked well when applied to complex, fixed functions — that is, human artefacts, such as aircraft, ships, buildings, computers and even EA software,” said Mr Robertson.

Is there really anything new here though?

An Agile Approach to Enterprise Architecture

I recently found a cool article by Scott Ambler on Agile Enterprise Architecture. I found his pragmatic, experienced based writings to be refreshing and useful. So, I decided to create a Knowledge Gene on this to make the key points easier to absorb and to use as a platform to extend executable components of the model. 

"When project teams work under the assumption that they can do anything they want, that they can use any technology they want, chaos typically results. Functionality and information will be duplicated and reuse will occur sporadically if at all. Systems will not integrate well. Systems will conflict with one another and cause each other to fail. Costs will sky-rocket..."

He identifies 5 agile 'musts':

1. Focus on people, not technology or techniques

2. Keep it simple

3. Work iteratively and incrementally

4. Roll up your sleeves

5. Look at the whole picture

What are your agile pain and joy experiences?

Click the link below to see the Knowledge Gene on this and the article (More Text):

Agile Approach to Enterprise Architecture (Scott Ambler) - coded by Ian Rainton

Riding the Hypergrowth Wave ...

I recently found a cool HBR article by Alexander V. Izosimov, the CEO of VimpelCom, who successfully rode the hypergrowth wave in Russia's cell phone market. He explains that when a market goes into hypergrowth - that steep part of the S-curve where market share is usually determined - established companies may be at a disadvantage. Corporate inertia can hamper their ability to respond quickly enough to increase their share. He offers five rules to help other companies survive a similar ride:

- Sell first and ask questions later.

- Don’t try too hard to innovate.

- Organize like McDonald’s.

- Push decisions out to the front line.

- Foster a can-do culture.

Hypergrowth is an experience that either kills your company or makes it much stronger. To survive it as a midsize or large company, you had better have the foresight - or the good luck - to establish the right kinds of organizational structures and practices.

Managing a company in hypergrowth is very much like Formula One racing. When you're learning to drive a racecar, you're taught not to fight the momentum but to ride with it. Mentally that means being both focused and relaxed.

Do you have pain or joy stories about riding (or being wiped out) by the hypergrowth wave?

I created a Knowledge Gene on this article to make the key points easier to absorb.

"Managing Hypergrowth" (Alexander Izosimov) - coded by Mark Robinson

6 business process management best practices you can't work without ...

I recently discovered a useful article "Discover 6 Business Process Management Best Practices" by Sally Slack, a business / technology author who specializes in "de-gunking complex topics so the masses can both understand and apply difficult concepts".

The author recognizes 6 best practices:

• Use a phased methodology
• Develop a process documentation guide
• Create a decision matrix
• Simulate, model, and test
• Communicate effectively
• Monitor the processes

I thought there was some good stuff in here although quite a lot to take in for busy folks so I've built a model (bottom link) to make the key points faster to absorb and to explore HOW these practices are executed and what benefits they bring in practice:

" Six BPM best practices you can't work without" (S S Slack) - coded by I Rainton

Manage Your Energy, Maximize Your Time ...

 

You can't increase the number of hours in your day, but you can increase the amount of energy you have…

Energy is defined as the capacity to work and is an extremely precious resource. It has the potential to expand in size and can be renewed easily and regularly, if you know how...

Time is the opposite - a finite resource that cannot be increased. We can't increase the number of hours per week, and the ability to fit in all elements of what are becoming busier and more hectic lives, is increasingly difficult.

Energy however, with its potential to increase, means you can increase your capacity to get things done. The theme of this Knowledge Gene (see link at bottom) is to move your focus away from managing time, and instead shift the emphasis to managing energy. You have the potential to improve your capacity to live life to the full; get the best of both worlds - improve performance at work, and enjoy your personal life.

To effectively manage your energy levels it is important to understand the notion of energy and its impact on your life, and to recognize the areas that use large amounts of physical and mental energy. With this knowledge, you can then take proactive steps and implement changes to better focus your energy. With the increasing demand and pressures that most people now experience, it is a natural reaction to slip back into sub-optimal energy use. By recognizing this decline and taking positive steps to manage your energy, it is possible to get more done in less time and improve your quality of life ...

Manage Your Energy, Maximize Your Time - by Susan Harley

10 Enterprise Architecture Pitfalls to Avoid ...

At a recent Enterprise Architecture summit in London, Gartner identified 10 common Enterprise Architecture (EA) pitfalls which I found to be a useful list. EA strikes me as a challenging discipline where carefull attention to detail can make the difference between failure and success. “The key for enterprise architects is to create not the perfect or most elegant architecture for the moment, but the most adaptable architecture for the future,” said Mr Bittler of Gartner

I've created this Knowledge Gene (bottom link) to make the key points easier for people to absorb and use. This Knowledge Gene is my interpretation of these pitfalls which I'm hoping will help us exchange ideas from experienced practitioners - to extend or adapt this model.

In your experience, are there any other pitfalls to avoid that are not included in this model?

"10 Enterprise Architecture Pitfalls to Avoid" (Gartner) - coded by Ian Rainton

Passing the Elevator test ...

Of the four components outlined in "Crossing the Chasm", by far the hardest to get right is the claim. It's not that we lack for ideas, usually, but rather that we cannot express them in any reasonable span of time. Hence the elevator test: Can you explain your product in the same time it takes to ride up in an elevator? Venture capitalists use this all the time as a test of investment potential. If you cannot pass the test, they don't invest!

This best practice describes how to create a fantastic elevator pitch and why it's important to do:

"Passing the Elevator Test" - coded by Mark Robinson

Complex process tools bore the pants of busy stakeholders ...

So many process diagrams lie unused in cupboards and many organizations document one thing then do another. Yes, we are architects of our own downfall by using outdated and un-necessarily complex process tools that frankly, bore the pants of busy stakeholders. In these circumstances, learning the tricks of the trade from each other seems critical. 

The link below is an example of a framework that's simple to use, verifiable and immediately understandable by busy stakeholders. As a practitioner, what are your thoughts on this? What are your pain or joy experiences when documenting and sharing business process? 

"Quickly, Simply & Effectively Document Business process" - coded by BCS

The link below is an example of a framework that's simple to use, verifiable and immediately understandable by busy stakeholders. As a practitioner, what are your thoughts on this? What are your pain or joy experiences when documenting and sharing business process? 

"Quickly, Simply & Effectively Document Business process" - coded by BCS

Thrive in leading edge digital environments - "Unleash the Killer App"

Technology drives today's economy. In their book Unleashing the Killer App, Larry Downes and Chunka Mui look at the dynamics of technological change and its potential to create products or services that displace unrelated older propositions, destroying and re-creating industries far from their immediate use (killer apps). Killer apps are all around us - the pulley, compass, moveable type, Apple Macintosh - and new ones are popping up all the time.

Drawing from their experience and research with leading global businesses, the authors identify the 12 fundamental design principles for building killer apps. They examine the economic consequences of the diminishing transaction costs in cyberspace; and describe how to integrate digital strategy into an organization's planning process to create new markets. 

You could use the Knowledge Gene below ("Unleashing Killer Apps") to help you identify and create killer apps in your organization...

"Unleashing the Killer App" (Downes and Mui) - coded by Ian Rainton

"6 Best Practices for Aligning Enterprise Architecture with Business Strategy"

A critical goal of every EA program is to increase the alignment of enterprise activities and investments with the business strategy, yet many EA teams struggle to achieve and demonstrate this level of business relevance. As a result, EA efforts either fail to deliver significant business value or are perceived as irrelevant to business success by the stakeholders. In the current economic climate, either of these conditions will likely be fatal to the EA initiative and/or to the members of the EA team. To help enterprise architects avoid these results, Gartner has collected a selection of best practices designed to ensure that business value is both delivered and demonstrated.

Gartner recently published '6 Best Practices for Aligning Enterprise Architecture With the Business Strategy' :

Key Findings

• A truly aligned architecture effort requires significant input from all the stakeholders in the enterprise. Successful EA programs engage all the stakeholders—not just senior business leadership.
• Interpersonal and facilitation skills are most critical to the success of the EA initiative.
• It is not permissible to forgo the business strategy analysis altogether just because a common requirements vision (CRV) cannot be delivered. The strategy analysis is the foundation of the EA effort, so some approach that captures the essence of the strategies and ties them to the EA concepts must be used.
• By using the EA guidance as the unifying principle, we ensure that the strategic and governance initiatives of the enterprise do not collide with one another, but rather cooperate to support the evolution of the enterprise to the desired future state.

Recommendations

• Ensure that all the stakeholders are engaged.
• Ensure that all stakeholders are approached with a straw model.
• Spend the majority of your time validating and socializing.
• Do not expect the business strategy to be delivered to you—be prepared to discover it.
• In less-mature enterprises, take a less formal approach to the development of the CRV.
• Use your EA process to inform other strategic and governance initiatives in the enterprise.alysis

Click the link below to see the Knowledge Gene on this which is an interpretation of these six principles plus some pragmatic ideas that I've tried myself with some success. Using the Knowledge Gene, I've tried to make the material easier to absorb and execute.

Do you agree with this model? Can you help extend it?

I'd be delighted to add to and change this Knowledge Gene based on comments you might want to make. It's my hope that together we can produce the most useful best practice model ever on this that will benefit many.

"6 Best Practices for Aligning Enterprise Architecture with Business Strategy" (Gartner) - coded by I Rainton

Extreme Programming Methodology ...

eXtreme Programming is a lightweight methodology for managing software development projects.

XP is a style of software development focusing on excellent application of programming techniques, clear communication, and teamwork.

XP was developed by Kent Beck in an IT Project at DaimlerChrysler in 1999. In summary, his philosophy is based on communication, simplicity, feedback, and courage as the four premises that drive XP programmers. XP has the reputation of being an innovation in software development and has experienced increasing prominence in the field.

XP differs from traditional methodologies in that it regards ongoing changes as an acceptable aspect of software development projects, which stresses the importance of software adaptability. The customer does not define end results of the project at the onset; but remains open and flexible to changes in the software throughout the duration of the project.

• Streamline and simplify the software development process

• Reduce missteps by designing, testing, and refining code in increments

• Receive clearer specifications and feedback from customers

• Conserve resources by planning and reassessing progress as you go

• Step up delivery dates, shipping the most crucial features first

• Improve customer satisfaction!

Extreme Programming Methodology - coded by Charlie Ludden

Information Without Knowledge

There's certainly no shortage of information coming at us. In fact, most of us suffer from information overload. And, given the same information, some people perform much better than others. How does this happen? Well, the answer has to be knowledge - knowledge is different from information. Knowledge is about understanding WHY a piece of information is important, and HOW to exploit it - that's why some people do well while others do badly with the same information - winners know WHY it's important and HOW to use it, losers just see information. And the more they see, the more they lose.

Regular readers will know that Peter Drucker is one of our major influences. So in his words:

"The first question in increasing productivity in knowledge and service work has to be: What is the task? What do we try to accomplish? Why do it at all?"

Optimizing the Enterprise Knowledge Base - by BCS

"Send three & fource pence, we're going to a dance" ...

  

There is a well-known apocryphal tale from World War I of a message being sent back up the command chain  - starting as "send reinforcements, were going to advance"  the message finished ridiculously as "send three and fourpence, we're going to a dance".  It couldn't really happen could it?

Well actually, a battle-hardened CIO around these parts likens this to the communication gap between many IT functions and their business communities. And communications failures do actually top the list of reasons for IT projects failure, according to poll results from the Computing Technology Industry Association, as reported in Information Week.

The solution is simple - make sure everybody on the team - management, users, information architects, software engineers - make sure everybody understands WHY, and make sure they have the same WHY. If this can be achieved then a big part of the problem is overcome. Then it's simply a question of understanding exactly WHAT, and exactly HOW. If these simple but powerful questions can be answered, and if they can be seen to be answered, then it's almost impossible for there to be a communication problem. How good would that be?...

Define Information Needs - coded by BCS 

Aligning Business and IT Strategy - coded by BCS 

There is a well-known apocryphal tale from World War I of a message being sent back up the command chain  - starting as "send reinforcements, were going to advance"  the message finished ridiculously as "send three and fourpence, we're going to a dance".  It couldn't really happen could it?

Well actually, a battle-hardened CIO around these parts likens this to the communication gap between many IT functions and their business communities. And communications failures do actually top the list of reasons for IT projects failure, according to poll results from the Computing Technology Industry Association, as reported in Information Week.

The solution is simple - make sure everybody on the team - management, users, information architects, software engineers - make sure everybody understands WHY, and make sure they have the same WHY. If this can be achieved then a big part of the problem is overcome. Then it's simply a question of understanding exactly WHAT, and exactly HOW. If these simple but powerful questions can be answered, and if they can be seen to be answered, then it's almost impossible for there to be a communication problem. How good would that be?...

Define Information Needs - coded by BCS 

Aligning Business and IT Strategy - coded by BCS 

Marketing is a battle of perceptions, not products ...

22 Immutable Laws of Marketing is a widely respected business book by Ries and Trout. Their basic thesis is that "to cope with the terrifying reality of being alone in the universe, people project themselves on the outside world. They "live" in the arena of books, movies, television, newspapers and magazines. They "belong" to clubs, organizations and institutions. These outside representations of the world seem more real than the reality inside their own minds. People cling firmly to the belief that reality is the world outside of the mind and that the individual is one small speck on a global spaceship. Actually it's the opposite. The only reality you can be sure about is in your own perceptions. If the universe exists, it exists inside your own mind and the minds of others. That's the reality that marketing programs must deal with. Most marketing mistakes stem from the assumptions that you're fighting a product battle rooted in reality. All the laws in this book are derived from the exact opposite point of view."

The book makes intriguing reading, despite the fact that it contains nothing startlingly new. Part of what makes it interesting is its counter-intuitive, contrarian stance on certain issues (for example the notion that product attributes don't matter in and of themselves, and that it is essentially the position of the product in the mind of the consumer that is the important thing). However, with twenty-two 'laws', there is something to cover just about every situation imaginable, so the book seems more prescient than it actually is. (In fact, given the fact that there are counter-examples to just about every rule presented by the authors, perhaps the only immutable law of marketing is that there are no immutable laws of marketing!)

We codified the key points for you to internalize faster:

22 Immutable Laws of Marketing (Ries and Trout)  - coded by Ian Rainton

Effective delegation is key ...

 
A situational leader is one who can apply different leadership styles depending on the situation.  Ken Blanchard, management guru and Paul Hersey created a model for Situational Leadership in the 1960's which has been a big hit with leaders every since due to its simplicity and the fact that it works. 

To get the best possible results from people, first consider the combination of the PERSON whom you're leading, and their COMPETENCE IN THIS SITUATION - in the task you'll ask them to perform, or the result you'll ask them to deliver. Then delegate using the most productive style to suit that situation.

'Competence' (or lack of) is meant in its most neutral, objective, non-pejorative sense. Roger Federer is probably an incompetent actor, and Tom Hanks would be incompetent on Centre Court at Wimbledon. Those aren't insults or negative personal comments, merely detached observations about their ability to shine in that particular situation ...

Click the link below to see the best practice framework on this ...

Situational Leadership (Ken Blanchard) - coded by Ian Rainton