CAN WE HAVE BETTER FRIENDS

CAN WE HAVE BETTER FRIENDS THAN TREE
DONATE BLOOD REGULARLY & DONATE EYES __.____._

CRM: Identifying Customers & Their Characteristics

The first step in developing a customer relationship marketing strategy is to gain knowledge of individual customers.  Using existing systems and services, create a list of all customers who receive the goods and services offered by your organization.

 

Gather Customer Data

 

The relationship management approach recognizes the unique characteristics and preferences of customers.  To learn about these factors, gather both the traditional transaction-based data about each customer as well as information about preferences and special requirements.  This may require additional research beyond the information available in current systems.

 

For example, the traditional data sources include:

 

·          purchasing history and products selected,

·          credit history,

·          demographics,

·          channels used for purchasing products and services.

 

The additional types of data that are not generally sought out but provide a basis for developing and strengthening customer relationships include:

 

·          personality type,

·          preferred mode of contact,

·          customer views on your organization’s products and services and those of competitors,

·          customer opinion of your organization in comparison to competitors,

·          preferences, expectations and special requirements,

·          influences.

 

Identify Chain of Influence

 

The value of a customer to your organization goes beyond the individual and extends to others who influence and are influenced by the customer.  For example, in a consumer relationship, a customer’s purchasing decisions are influenced by and influence family, friends and co-workers.  In a business to business relationship, the chain of influence includes the customers, suppliers, intermediaries and partners who work with your customer.

 

As part of this data gathering exercise, identify the businesses or individuals that form the chain of influence for each customer.  Sources for this information include referrals, purchases on behalf of other individuals or businesses, relationships with other individuals within your organization (e.g., friends, family, investor, and professional associations).  On an ongoing basis, this information is collected during interactions with the customer.

 

 http://blogs.ittoolbox.com/eai/implementation/archives/crm-identifying-customers-their-characteristics-20556

Project Defination: Why, What, Who, When and How?

Project Definition - Why, What, Who, When and How?

The project definition phase lays the groundwork for obtaining information about the project and provides a shared understanding about its objectives, sponsorship, costs, benefits, timeframes, resources and mandate. The following template presents the fundamental things that should be clearly agreed at the commencement of a project. They form the basis upon which the project and project stakeholders will be defined and measured.

Management Priority and Strategy
Describes why the project is being initiated, the priority of this project in relation to other projects underway and the strategy to deliver the project. It may include a business case or at the very least a project request form that answers the questions: How does this project align with our strategy and what are the expected benefits to the organization upon completion of the project.

Organization Structure and Roles and Responsibilities
Identifies the project organization's structure and describes the roles and responsibilities of the project sponsor, manager, team members and stakeholders throughout the project life cycle. The roles, responsibilities and deliverables of external vendors, companies and/or individuals also need to be documented. It is important to identify who must sign off on various project management documents in this section.

Project Change Control
This section describes the process for requesting, approving, denying and managing all project changes. A turn around time service level agreement should be established among all stakeholders to analyze the change request, determine its impact to project cost and schedules and obtain a decision to approve or deny the request.

Project Metrics
The project manager and executive stakeholders should define and mutually agree upon the project metrics to be used to measure team member performance and/or organizational project management performance. Criteria for project success should also be defined for reward and recognition of team members for successfully completing the project.

Budget Overview and Cost Control
All cost and budget considerations for the project need to be identified such as labor (internal and external), equipment, software, web-hosting, travel, lodging and meals, training, documentation, maintenance, facilities, and reward and recognition. A spreadsheet of changes and variances to budget must be maintained and the spreadsheet should be closely linked to changes approved via the project change control process.

Key Assumptions
Key assumptions are expected factors that for planning purposes are considered to be true, real or certain. Examples are:

 

Team members will be afforded the appropriate time to complete assigned tasks within established project timelines.

Business unit and IT management will communicate to appropriate management what work is being re-assigned or delayed due to the time allocated for resources assigned to this initiative.Key Constraints
Key constraints are known factors that restrict the available options. Examples are:

There is a budgetary constraint of $XX for training.

The solution must be built on our existing software systems. No off the shelf products will be introduced.External Dependencies
External dependencies are other programs or projects whose timelines may be impacted by this project or other programs or projects whose timelines impact this initiative.

Project Risks
This section identifies the major risks, the probability of occurrence, the impact to the project if they occur and what actions will be taken to mitigate and/or eliminate the risks.

Resource Requirements
Resource requirements should be spelled out very clearly regarding how much time is expected per day/week of each individual assigned to the project.

Communications Plan
This section describes what communication methodology will be used to ensure all project participants and stakeholders are kept informed of project information such as progress, slippage and risks.

Management escalation process
This section describes specific mechanisms used to assist in management control over the project. This section describes the process to escalate issues or problems that cannot be resolved at the project level within the organization. This section also describes the threshold at which point the project sponsor wants a delay escalated to his/her level.

Management Review
This section describes the process for reviewing project status by the project sponsor, manager, team members, executive steering committee, and other project stakeholders as required. This section focuses on the process to ensure management oversight of the project. Oversight will provide early detection and correction of potential or recognized problems that affect project delivery.

It is important that the project definition is fully understood and agreed by all persons concerned. The details should be incorporated into a document, formally signed off by the project sponsor, manager and team members and communicated to all interested parties. Once the project is adequately defined the team will be better positioned to move on to the business requirements, scope definition and project planning phases of the project and hopefully avoid the need for a project review and recovery plan.

http://blogs.ittoolbox.com/pm/leadership/archives/project-definition-why-what-who-when-and-how-20530

Developing Authentic Leadership

Last night I gave a talk on “Agile Project Leadership” at the Calgary Agile Methods User Group (CAMUG). I like giving these because the questions raised make me re-examine elements of leadership and last night was no exception.

One question raised was basically “We hear about these ideas and they sound good, but in our projects the same old stuff keeps happening. How do we get real results?” I responded with some explanation about encouraging servant leadership, but in retrospect I think the underlying question was more about making the switch to authentic leadership rather than shallow imitations that bring poor results.

 

Some subsequent discussions with a couple of attendees have helped me straighten out my thoughts on the issue further. “Cargo cults” is the term used to explain the phenomenon of blindly replicating outward behaviour with the hope that it will yield positive results. It originates from a few scattered instances of Pacific Island tribes recreating replicas of the war time aircraft runways, control towers, and radios out of wood in the belief that they would bring back the cargo planes that brought Western goods during the war.

 

The equivalent cargo cult leadership pattern would be to practice techniques like team recognition in the hope that it improves morale and productivity without understanding the work undertaken, or by presenting phony “well done’s” and insincere praise. People have excellent BS radars and phony praise is quickly recognized as attempts at manipulation and has the opposite effect as desired. Likewise mechanical-only attempts at creating a common vision, challenging the process, or creating empowered teams will fall short too. These activities require deep conviction or else they will falter and fade, making genuine attempts harder to introduce later as an “antibody effect” of mistrust develops in the team.

 

A quote I like on the subject is that “Leadership can not be taught, but it can be learned”. This addresses the idea that people have really got to buy-into the benefits of leadership for themselves in order to grow and be effective. We can teach most people mechanical techniques like estimation and risk management best practices, but when it comes to the humanistic based techniques, they need to be embraced and believed by the practitioner to be effective.

 

So how do we get this to happen? When I’m feeling lazy I am tempted to revert back to the idea that we should just focus on the people who “get-it” by mentoring and supporting people willing to absorb these ideas and leave the skeptics to their own self-limiting environments. Getting the “right people on the bus” certainly has its place, but as leaders we also have a duty to help develop the best from our team members.

 

Another attendee last night pointed me to the book “Powerful Project Leadership” and the quote “Managers use people to accomplish work; leaders use work to grow people”. I like this a lot. My take is that we have an obligation to lay an appealing trail of breadcrumbs to lead people along the path of figuring-out stuff for them selves.

 

What the breadcrumbs look like and where they go depends on the skills and needs of the person, but a reasonable starting process would be:

1. Ask them what they want to do


2. Ask them how they feel about areas for improvement


3. Provide resources (training, books, mentoring) in areas they have an interest for


4. Encourage “outsight” (input from people outside the organization) in their development


5. Checkpoint regularly about how the process is going and if their goals have changed

For reluctant team members the process will be slow to start as responses of “Nothing” and “Nothing” to the first two questions are hard to build on. However, with some creativity and knowledge of their roles some mutually agreed to development areas, even if very small, should be possible to identify.

 

Not everyone wants an aggressive development program; sometimes people have enough change in their lives that work is their last vestige of sanctuary. However, most people recognize they should not stand still for long and a development plan will not only help with their career development, but is a tangible example of investment in their welfare by the organization or team.

 

So while I still believe this leadership stuff needs to be truly believed to be grasped and used effectively, I hope there are ways we can assist with the learning process to help people get there quicker.

 

source: http://leadinganswers.typepad.com/leading_answers/2007/09/developing-auth.html

 

ALWAYS ALLOW THE BOSS TO SPEAK FIRST

A junior manager, a senior manager and their boss are on their way to a meeting. On their way through a park, they come across a wonder lamp. They rub the lamp and a ghost appears. The ghost says, "Normally, one is granted three wishes but as you are three, I will allow one wish each" So the eager senior manager shouted, "I want the first wish. I want to be in the Bahamas, on a fast boat and have no worries." Pfufffff. and he was gone. Now the junior manager could not keep quiet and shouted "I want to be In Florida with beautiful girls, plenty of food and cocktails." Pfufffff. and he was also gone. The boss calmly said, "I want these two idiots back in the office after lunch at 12.35pm." MORAL OF THE STORY IS: "ALWAYS ALLOW THE BOSS TO SPEAK FIRST"

Team Solving: The Under Utilized Power

All projects face problems, but fortunately your team members have the best solutions.Projects rarely go exactly to plan; they have a nasty habit of uncovering gnarly problems that were not anticipated, but need to be solved. This is illustrated nicely by Doug DeCarlo in his book Extreme Project Management.



The top black line depicts the planned approach moving in orderly fashion from start to finish. The lower blue line depicts how projects really progress with side tracks and setbacks as obstacles are encountered and overcome.

Yet, in attempting to solve these problems project managers too often overlook the best source of solutions, the project team. In this post I will outline why the team has the best practical solutions even when they may not be the best theoretical solutions. An example will probably help about now.

While managing a government project during an IT vendor change, we needed to quickly build rapport with the business users of the system and subject matter experts (SME) in order to maintain the development pace from the previous team. The problem faced was how do we get to know the business folks better and connect the team members and SME’s . Rather than contriving some project social event and trying to get buy-in from the business and team I presented the problem to the team in a planning meeting.

After some back and forth a team member suggested, that since quite a few of the business people went 10-pin bowling, then perhaps we should arrange a bowling social event. Others concurred, ideas for mixing the teams up (not us vs. them) were brainstormed and we ran the event. It went really well and led to other activities all of which greatly contributed to a strong relationship and a successful project.

As the PM I could have instead consulted the PMO, HR, or social psychology experts to determine the optimal team building event, but then I would have had to have sold it to the team. Here lies the first power of team solving:

Team Solving Power #1: By asking the team for a solution we inherit consensus for the proposal

The fact that the solution came from the team and not me, meant I did not have to sell it, it already had support. It is easier to steward a sub-optimal solution with good support to a successful outcome than build support for an optimal solution and ensure its successful execution. If challenges arise and people subconsciously ask “who’s bright idea was this?” the answer comes “Oh yeah, it was ours” and they are more likely to continue.

Team Solving Power #2: Accessing a broader knowledge of the facts
Team members are closer to the details and bring additional insights other than your own. I did not know that the business folks bowled, this was collective knowledge (Chris knew three users bowled and Julia knew two SME’s did also) together we found a new piece of useful information. Asking the group taps the collective knowledge of the team.

Team Solving Power #3: Solutions are practical
Anyone who has worked hard to craft a solution only to be told “That will not work here because...” will know how frustrating and disheartening these words are. Team sourced solutions have been vetted for practicality and, because created internally, solutions found for implementation issues.

Team Solving Power #4: When consulted people work hard to generate good ideas
The simple act of asking for suggestions engages team members beyond the role of “Coder” or “Tester”. People appreciate having their inputs valued and generally work hard to create innovative and effective solutions.

Treating workers as interchangeable resources is a poor model inherited from the command-and-control methods of the industrial revolution. Leading companies such as Toyota and 3M recognize that their best ideas come from inside their companies and we need to make use of this intellect. It is partly due to these methods that these companies innovate better, have higher quality products, and better labour relations.

Team Solving Power #5: Asking for help shows confidence not weakness
Asking for ideas and solutions to problems is not a sign of incompetence or an inability to manage. Just because we ask for input it does not follow we are dumb. Instead it demonstrates valuing the opinion of others, and being thoughtful.  In essence it demonstrates how all problems should be tackled, which is the next power

Team Solving Power #6: Seeking ideas models desired behaviour
Project managers have a leadership role of “modelling the desired behaviour” i.e. behave as we wish others to behave. If we stay silent, make decisions with incomplete awareness of the facts, and do not ask for help when we need it, what message is this sending to the team? Well, it is an obvious message that we expect team members to behave the same way and work in isolation. Lots of time and money is wasted on team building activities that are then eroded my management-in-a-vacuum.

By demonstrating good problem solving techniques team members are encouraged to solve their problems this way too. Teams that can effectively problem solve and build support for solutions are the real powerhouse of successful projects. We need to make sure as a leader we are supporting and mirroring these best practices

Usage

People do not want to be treated as work drones, ask them to think and they will amaze us with innovative, practical solutions that have great backing from the people that need to implement them. I used a trivial example of a team building activity because it was quick to explain, but this approach works best on complex, embedded process problems that would take days to outline to an expert. The team has the first-hand knowledge of the problem and more importantly, knows what is practical to solve it.

Of course this is no silver-bullet or panacea. Here are some cautions we need to be aware of.

Cautions

Real problems - We should use this on real problems only, not on which brand of printer toner to buy. Remember we are modelling desired behaviour and if people take it too far and consult their team mates when deciding what colour dialog box to create; no work will get done. It is a tool for when you are stuck and the problem is important.

Poor team cohesion – If the team is fragmented and has opposing groups then resentment for “fixing their problems” will undermine the process. We need to get the team aligned for team solving to be most effective.

Team and Project Changes – Over a long period if a significant portion of the team changes, we need to re-canvas the team to ensure they are still on-board with the approach. Exercising the bright ideas of others is nearly as bad as not being consulted; we need to ensure people still agree this is a good policy. Likewise if the project changes significantly, we need to checkpoint in light of these new facts and get the team to review the approach.

Follow-through – once you ask for solutions make sure you follow through on them with execution. It is pretty demoralizing to be asked to work on a solution and then see it wither. It is fine to go back with implementation problems that need to be solved, but don’t waste peoples time by asking for input and then ignoring it.

Summary
Your team has the best solutions to your project problems. It is ironic that Toyota proved they could engage the internal problem solving skills of a workforce previously written off as a “hostile, uncooperative and lazy” by GM management to turn around the NUMMI production plant in Fremont, CA; yet most software projects are populated by smart, well educated people and we treat them like production line robots.

People relish inclusion and an opportunity to solve problems so unleash the Team Solving power on our projects.

(In a future post I will outline some tools and facilitation techniques to help run these problem solving meetings, but for now a great way to start is to outline the problem and all the issues candidly to the team, ask for help and then shut-up while they discuss solutions.)

source: http://leadinganswers.typepad.com/

what Alexexmachina says...

 

To Kill A Project: Part I - Timelines

 

Alexexmachina (Technical Specialist) Posted 11/2/2007

In my experience there are common behaviors, paradigms, attitudes and fallacies which permeate the management of IT projects that are directly responsible for the obscene rate of project failure. In the first part I'm going to talk about how unrealistic timelines will ensure failure.

The number one attitude I see blowing timelines and killing projects is something I call "false urgency". False urgency is creating a false atmosphere of time pressure for no justifiable business reason. An example of false urgency would be me insisting on an arbitrary deadline as though it weren't arbitrary. There are enough time pressures on a project team to make reasonable deadlines while hitting all the functional requirements and ensuring quality in the design and implementation of your solution. Why decrease your chances of getting something you actually want just because you've grown accustomed to our cultural 'I need it yesterday' syndrome.

Here's what you're either too busy to notice (or forgetting) when you rush an IT project: it won't get done like you need it to get done. Then you'll do one of two things, you'll throw it out, which means you've wasted resources, time, money, opportunity and demoralized the project team or, even more costly, you'll make a sunk cost justification (if you don't know what that is, read my post on sunk costs here) and try to salvage the project through endless iterations of continuous failure.

It's a lose-lose situation which will put a serious drain on your budget, your patience and your sanity. Is this the only thing causing unreasonable schedules? On rare occasion I've seen timelines emerge from real business requirements which have an absolute inflexible deadline. Although you can't really do anything to change those deadlines, there are other ways you can adjust.

Expect to hear this next bit from me over and over again: Time, cost, resources and quality requirements are inversely proportionate to the quality and scope of the deliverable. Duh, right? Because I'm a particularly slow learner when it comes to setting realistic expectations for individuals managing IT, I am continuously astounded that those individuals have managed to obtain jobs in management while failing to grasp that very simple concept. In case I was vague or you didn't catch it, I'll put it another way: you can't make a gourmet lasagna for four with no recipe, a broken oven, moldy cheese and $2.00 of ingredients. There are individuals out there who will tell you that you can, but I assure you they are either lying to you or they're idiots.

If you find either of these factoring into why your projects aren't making their deadlines, don't feel bad. I'm not actually suggesting that its simple or easy to manage project timelines and I don't have 10 steps to guarantee you can do it successfully every time. (if I did, I'd write the book and retire) But I have been fortunate enough to work with exceptionally gifted managers who taught me a sane way to get reasonable time estimates and work within time constraints. Next time you're ramping up a new project, consider this:

• Assess the business drivers behind the need:
  
  
  
  • Is there actually a fixed time line associated with the need?
  
  
  • If there is a fixed timeline, what additional costs can you support?
    
    
    
    • Additional budgetary costs?
    
    
    • Additional resource costs?
    
    
    
    
  
  
  • What consequences can you live with?
  
  
  
  


• If your requirements are reasonably complete, request a conservative estimate from the project manager.
  
  
  
  • Did he ask his technical leads?
  
  
  • Did they account for QA and bug fixing?
  
  
  
  


• If their estimate is unacceptable you have one of three options:
  
  
  
  • From the beginning provide whatever additional resources they need to complete the project.
  
  
  • Cut functionality down and plan future feature releases.
  
  
  • Start planning for the disaster recovery, because your project will fail.
  
  
  
  

Now, as I will talk about in my upcoming post on Defining Project Failure, qualitatively, some projects may 'fail' less than others and get you what you need by the date. But don't think those failures don't carry additional, sometimes hidden, costs. As someone who felt forced to leave a position because of constant, unreasonable time pressure, I can tell you that high turnover can be one of those costs.

I hope this has been helpful to someone. Unfortunately, my experience has been you either get this or you don't. Getting this point across to someone who's been managing IT projects under unreasonable deadlines for a while is near impossible. They believe that missing functionality, low code quality and missed deadlines are just part of the business. As someone who's seen it done right, I can assure you they don't have to be.