These emotions, all part of every day life must be controlled in the business environment or danger lurks, as emotional decisons will in all likelihood fail to materialize as desired and are the base cause for making incorrect decisions and thus are self defeating.

The interesting part of this is we all know when we are doing this, we all have our little voice in our head, the feeling in the pit of our stomach warning us that this is an emotional decision and not necessarily the right business decision, but we all let ego win from time to time, as it is a very strong force...and when the mistake occurs we ask ourselves, "Why did I do this"? The answer is clear, we made an emotional decision that satisfied an ego driven need not a business decision that satisfied business requirements.

Hiring, firing, purchasing, paying, buying, growing, contracting all can either be decided based on merit, budgets, analysis. Not to diminish the power and need for intuition, which is different then ego driven emotion.

The biggest claim on our saner business mind is the need to have others think well of us, or said differently our concern for what others will think of us, thus we make decisions around protecting this area of sensitivity. 

Emotional self sufficiency is the objective here, being strong enough to be satisfied with our own self evaluation of who we are and what we are doing so we are not driven by what others think of us, but what is the best or right business decision for the situation. That is a real challenge but if we take this battle on, identifying ego driven decisions as the demon we must all face, we have a better chance defeating it when it pops its ugly head up and insists you do the wrong thing for a variety of bad reasons....excuses I will call them, excuses from doing the right thing even when we know the right answer or response or strategy.

This does not mean we must rid ourselves of passion, definitely not, passion is a wonderful driving force, which plays a large roll in fueling an entrepreneurs spirit to reach his goals and aspirations.

Nor does it mean you cannot have a vision, of course you may in fact you must or how do we get to where we want. Unbridled passion unchecked by logic can lead one to excess and bad judgement, but passion has a distinct roll in the plan as long as it is not controlled by ego or other less helpful emotions.

Think back at some bad decisions you may have made and review why you made them, and if you knew they were bad decisions but you chose to ignore the warnings you generated internally. We all have done this.

We can however rid ourselves of this as a controlling factor and check ourselves if we begin to allow ego to prevail. It can be done, it simply requires diligence and perseverance and yes emotional self sufficiency. We do not require others opinions to support our best decision making. We do require sound business analysis. 

You can do this, you must, if you intend to succeed.

• Business Case
• Business processes that involves for the new changes
• Functional Specification that involves expected system flows, data model for the new changes.

At times, we are overwhelmed with the detailed contents of the document as this document supposed to compile the overall implementation and processes to be delivered from the desired outcomes.  This often results in not understanding what exactly we should be looking out for that have impacts or new changes to the Operations and systems involved.  In most times, we are always stuck on what questions to ask ourselves when trying to understand the documents.

Questions to ask ourselves:

1. Which existing business processes is/are affected by these new changes?
2. How these changes in the existing business processes affect the system design for the new changes?
3. What new technology is being involved and the resources require to manage this new technology?
4. Which data model/mappings is/are affected by these new changes?  How these changes are affected from the changing business processes.
5. Which users are affected and what types of new training to be involved to cater these changes?
6. How the existing administration of the data are being affected?
7. How the existing Service level support affected by these new changes?

1. User involvement was limited (at times or all the time).
2. Scope change/creep.
3. Ran out of time or money.
4. Vision was different on all sides.

A book can be written for each one of the above reasons (and probably has). The truth is, it is probably a combination of them all. When I talk to the business community, either those in the trenches or executives, I get this common response to a rollout system: "It's not what I expected."

Before this ruffles your feathers...think about it. Many technologists tend to get right to the details that they forget the overall intent of the project. They work with knowledgeworkers that understand their process in great details. Getting caught up in the develoment process, it is easy to forget the business why this is needed. What was the business objectives? What was the executives intent for this system?

The core of the idea for any system should be simple and to the point. It should be posted on every document and in every person's cube that is involved in the development. I'm not talking mission statement. (Can you recite your company mission statement?)

I'm talking about the simple core of the projects purpose stripped down to its most critical essence. Unless you understand the core business issue, all participants will have a different 'vision' of what needs to be done and how it should look and feel. Once everyone understand the core, all decisions can be made quickly to support it. All designs can be made flexible enough to change with the growing scope creep or need for answers if it satisfies the basic core. Plans can be adjusted and money can change...if you at least support the core.

This idea on finding the core is from Made To Stick by Chip Heath & Dan Heath. It focuses on the corporate message but it can be extended to defining the essence of any project. It is hard to define and must be done so jointly by the business community (approved by executives) and IT.

My name is Thiesha Jones-Frazier and I attend Axia College University of Phoenix. I will be 30 years old on August 15. (The BIG 30) I live in Savannah, Georgia with my husband and six beautiful children whom I adore. My college experiences have been great thus far.

I am attending college to obtain a PhD in Psychology; and I wish to work with families and children within my field of study.  My son has ADHD, and his situation has inspired me to learn more about the human body and the way that one think and learn; also I am interested in ones behavior, emotional, and psychological patterns as well. I have a theory concerning any child that has been diagnosed with ADHD and ADD, and by the end of my studies, hopefully I will be able to prove my theory.

I have several missions, goals and desires that I would like to accomplish before it is my time to leave this earth. I have always been interested in working for myself; and for the past three years I have been developing business strategies, plans, layouts and analysis that concentrates on particular business structures for small business owners and home-based business owners; along with the general concepts of owning and operating ones own business.

I am also interested in writing. I have written several articles that have published. I also will like to write books/novels. Although my grammar is not so hot, I plan on taking extra courses in grammar to help me achieve my writing goals.

I love building and managing web sites, publications, and blogs, and so on. I like to design and be able to design and show off my natural talent of “an eye for art”.

I am a hair and nail designer, though I choose not to go full force within that field because my life is so busy right now and I do not have the time to devote into designing hair or nails, although, I do it occasionally to earn extra pocket change. All money is not good money, but some money is better than none.

This concludes my biography, I hope that everyone has learned more about me, what I do and what I want to accomplish.

Mrs. Thiesha D. Jones-Frazier

Two things: in programming it is often difficult to just add features to an existing software system. In this case because I don't have the source code and can't just glue new stuff onto the existing code. Another situation is where the existing system is so incredibly old (like in COBOL and CICS) your programmers won't touch it and tell you it has to be rewritten from the ground up. Well, recreating all the old stuff is very difficult and expensive. For me, it isn't worth it. Better to adapt myself to what Scrivener offers. And bend Scrivener to my evil intentions. 

Second, I got to thinking that if we were in this beginning systems analysis class and I told the students to write the requirements for a 'word processor' I could expect them to write the requirements for Word. Not because Word is the last word in word processors but because what we are used to is the foundation for what we desire. (What was the line in Silence of the Lambs? "We covet what we see...every day"?) We have to be careful about this constriction of vision when we practice business analysis.

More on both thoughts next time...

One of the fundamental assumptions that underpinned the initial analysis and business case was that the UK operation would substantially adopt US business processes and organizational structures.  This lead to the assumption that the level of system change required would be relatively small.  One of the basic implications of this assumption is that UK business users would be required to significantly change the way they do business, which implies additional work, disruption, and discomfort as they go through the required transition.  Those business users are the same resources that must give shape to the project and provide input to the requirements, analysis and design process for the (inevitable but presumably minimal) system modifications that will still be required to support the UK business.

 As we’ve moved through the project there have been hundreds, probably thousands of decisions that have needed to be made that have hinged on whether the UK must be able to continue to do things the way they have with their current system (with the associated system development time and cost to modify the new system) or can change to doing things a new way.  Unfortunately, but unsurprisingly, the individuals charged with making those decisions are almost always deciding in favor of additional system development to support doing things they way they do now.  This is unsurprising because in most cases they have almost no incentive to make a change, no matter how small it is, and there is almost always a cost to adopting a new process.  In some cases, the cost to them may simply be learning a new way of doing things, in others, they may actually be giving up a level of functionality to which they’ve become accustomed.  In addition, they may not know if the way things are done now is truly necessary, due to market or internal convention, or due to current system limitations, so they’ve generally erred on the side of caution, assuming that things are truly necessary if they’re not sure.

Counteracting the tendency to want to maintain the status quo is the desire to keep project time and cost down by adopting US processes & existing system functionality.  As IS is, in large part, managing the project and is the primary source of cost & time to implement new functionality to support UK business processes, IS has been asked to attempt to keep this under control.  But of course IS has no authority to enforce it (and rightly so).  If IS starts to say no to a significant number of the system changes requested by business users as a result of the day to day decisions, we lose their support.  If we lose their support, they’ll stop participating, and without their support and participation, the project will fail.  I believe IS has pushed back as hard as we can without alienating the users (too much, anyway).

With a project the magnitude of what we're undertaking, that touches all parts of the organization and that requires significant compromise between parallel user groups in the US & UK (i.e. reporting lines for stakeholders and participants only meet at the CXO level), the only people with any ability to enforce the change required by the original business case are senior executives.  Even at the level of the workstream leads, the incentives are pretty weak to force major change to business processes.  It’s also extremely difficult for a senior executive to effectively manage the decisions that are resulting in the increase in project scope.  The increase in scope has largely been the result of a large number of small decisions made at the line management level and requiring detailed knowledge of specific business processes and system functionality, rather than a small number of large decisions that can be readily made by a senior executive.

I would also argue that the original assumption (that the UK would be willing to accept the business processes implicit in the new software, i.e. the US business processes) is fundamentally flawed.  A project of this magnitude requires significant support and effort from just about everyone in the business, and ultimately requires buy in and acceptance from a large majority of end users.  Given that there’s little tangible short term benefit to those end users to make the changes and put up with the disruption that are implied by that basic assumption (however small they may be, and unfortunately, in this case, they're much larger than anticipated), I’m not sure you would ever have the level of support required for the project to be successful.  To get their support and participation, you need to offer them some short term benefit, which will (has) result in increases in project scope.  Stakeholder and project participant incentives need to be aligned with project outcomes and objectives in order to have a chance at succeeding, and I’m not sure the original business case assumptions left enough room for this.

Three other related (and probably more obvious) issues/assumptions are/were:

We assumed that US & UK businesses were fundamentally pretty similar, and that adopting US processes wouldn’t be too difficult.  I think this was probably a bit optimistic, and that we had an insufficient appreciation of the difference between US & UK business processes (and the reasons for/ability to overcome those differences)

Insufficient appreciation of the level of additional functionality required to support the UK market environment – we thought we were 75-90% of the way there with the existing pilot system.  We were more like 10-20% of the way there (which implies a multiplier of 3-9 times original estimates).

The benefits of standardizing on US processes and system functionality mostly accrue to the global organization in the form of lower project cost, cost savings from consistent, streamlined business processes, and improved sales & marketing capability enabled by the system.  In the long run these should benefit individual employees through greater company profitability, but at the cost of significant short term disruption, up to and including the loss of a job for some employees.

--------------------

Here’s an example, from a very recent e-mail discussion of system design.  While this is not specifically related to doing things the US or UK way (as the functionality in question is UK only), it’s indicative of the way decisions have been made.

(Me) If the same customer has advised two amounts (e.g. under separate reference numbers), could those go in separate message segments, or are they required to be in the same segment?  It would be simpler to implement if it’s acceptable to report them under separate segments.

(Business User) They are required to be grouped and cannot go separately. The reason for this, is that custoemrs get charged £?? per segment and this is a mechanism they use to keep their costs down.

(Me) OK.  We’ll adjust system design accordingly.  Out of curiosity, how often does this happen and how much do they get charged per segment?

(Business User) It doesn't happen a great deal of the time but when it does it stays with the contract throughout its lifetime, but that's irrelevant really. Underwriters are motivated by cost savings and we are obliged to assist them in doing so by using the system in the most cost effective way. The ballpark figure is £1 per segment depending on volume.

While it may seem ridiculous, this is an entirely rational response on the part of the business user.  If we do not implement the more complex method, they’ll be criticized by their customers for not supporting the cost saving strategies that they have in the past (this flexibility is currently available in their existing system), even if the cost savings is only a few hundred pounds a year.  The only benefit to them of giving up this functionality is getting the new system implemented slightly sooner, and for slightly less cost.  Given the choice, the users will take the longer project time to get the functionality they want.  We've estimated that the functionality required to implement the more complex method will add 3-5 days of effort to the overall implementation, including design, development, QA, UAT & Integration Testing. Take the few additional days for this one decision and multiply by the hundreds or thousands of similar design decisions that have been made and you end up with big numbers.

If you've gotten this far in the post, you've probably realized that there are a lot of issues to explore here, but as this is already a long post, I'll take them up in subsequent notes.

1. Always make sure the Developer is doing what is needed and anything other than that, the BA has to stop it from moving on.

2. Always make sure there is a genuine mistake before raising the flag. Dont be in a hurry to do it, look at the specs before doing it. I looked at the wrong place for the link without checking out the spec.

3. Always ensure that protocol is being maintained and dev and db folks are ok with whats happening.
In one instance, the developer went and finished the ticket while he did his part as well as the db guys part, which is against protocol. I should have raised the issue earlier and should have ensured that protocol and responsibilties are being maintained.

The moral road is to make decisions based upon what is best for the project, thinking that will help the company strive to new heights. Ethics relate to doing what you are paid to do…follow the direction of your manager and company.

Technicians tends to weigh moral decisions higher than ethical decisions. It is a black/white thinking that forgets that reality is really gray. The combination of making decisions based upon morality and ethics.

This continued battle creates stress for the technician. Being 100% ethical, makes you a “yes man” or “empty suit.” Being 100% morally right, makes you “closed-minded” or not a “team player.” You may see how another approach (as directed by a manager) can lead to a train wreck. You know that your way will help the company grow but are stopped at every opportunity.

The conflict is within your self. You need decide your compromise point. Is the manager’s approach going to get a “good enough” solution? Sure, it’s not the best but if you can accept a lesser success rate in your mind...live with it. If the solution really will hurt the project or company and you can’t live with that, start looking for another opportunity. Fighting against the ethics for the morally-right solution will get you laid-off or fired.

Understanding and accepting the continual conflict between moral and ethical approaches will help you find avenues to negotiate and persuade. It will help you live in reality which is gray. Accept that ethical decisions are part of any final decision.

Through my eZine and here, I'm trying I stress that technologists improve their own personal brand with the business community. Therefore, I dare you to submit this list (after you checked your own list) to your business users. Try by giving this to a business user you do get along with and one you don't. I'll ask you the same question that Lesley asked the readers...Do the Lists match?

Here's the list (I switched two words between columns from Lesley's list):

Here's a hint. Left-hand side of the list is what the business cares about when interacting with you.

I've never encountered this anywhere else, although I'm sure it's not a totally original idea.  The basic concept is to categorize distinct functional requirements into groupings and put them in order of priority.  Structuring the resulting data into a matrix and drawing a zig zag line through the matrix to indicate the cutoff for items in and out of scope offers a concise presentation of scope for a project.

One of the major benefits of the presentation is that it concentrates attention on the marginal items.  As with most portfolio management problems, most people will agree on the top priority items and the lowest priority items, but will struggle to come to agreement on the stuff in the middle.  You don't want to waste valuable meeting time on discussion of things on which everyone agrees - you want to cut straight to a review of areas where there may be disagreement.

At Axiom, part of the scoping methodology was to include an assessment of the effort required for each area.  Granted that early in the process these numbers are pretty fuzzy, you can generally at least get to a small/medium/large categorization, and attaching effort ranges to these categories allows you to do some scenario analysis.  With a little Excel magic, you can even build a tool to calculate total estimated effort as you adjust in scope/out of scope decisions on individual functional items.

Everyone is different but I will recommend things that are outside what everyone knows (like update your resume).

1. Get Googlized...you need an Internet presence. All potential employers will look to see what is being said about you on the web. Join LinkedIn and other social networks.

2. Start writing. Register your name as a domain. Create a webpage AND blog. Keep them focused in your area of expertise but friendly. A winning combination.

3. Prepare for possible interview questions. Yes, they still ask that useless question "what is your biggest weakness?" Think about how to explain any potential "elephant" questions pertaining to any out-of-date skills, long commute, etc.

4. TURN OFF THE TV AND STOP GAMING! Start reading books that will help you get a better job. Books that will improve your attitude. Books like:

• - Jeffrey Gitomer's Little Gold Book of YES!Attitude
• - Napoleon Hill's Think and Grow Rich
• - Earl Nightingales's The Strangest Secret
• - Harry Beckwith's You, Inc.

All of these suggestions will help you be of real value to the business community. Business people prefer long-term relationships...otherwise you're just an outsourcable commodity! Spend your time sharpening your marketable skills.

Fast-forward to Chaos statistics from 2007 and we see an improvement in these figures: 35% of all projects were successful, while 19% were failures. Fortunately these numbers have improved over the last decade or so, although the success rate of software projects in general is still unacceptably low. Why is it that such a large number of projects fail?

According to respondents in the first study above, ‘Incomplete Requirements’ is the number one reason why software projects are impaired and eventually abandoned. There are a number of other important reasons listed, including ‘Lack of User Involvement’, ‘Lack of Resources’, and ‘Unrealistic Expectations’, but generally speaking the issue of inadequate requirements has been a longstanding pain point within the software development industry. I am certain that like most software developers you too have experienced the frustration of requirements issues at some point, maybe due to those all-too-common reasons such as insufficient research during the requirements gathering phase, or misunderstandings in communication between the customer and the development team.
Oftentimes development teams fail to understand requirements because of documentation that is vague or open-ended. Unclear requirements leave a lot of room for interpretation, meaning that the customer, managers, developers, and any other parties involved may understand requirements differently from each other. As a consequence a development team’s interpretation of a system may be different to what was envisioned during requirements analysis, and again different to what the customer expected.

The truth is that requirements analysis is an inexact process, and that scope issues are going to surface in most software projects. While these types of issues cannot always be avoided we should try our best to ensure that we understand all requirements in as much detail as possible and as early on in a project’s lifecycle as possible, to minimize the likelihood of these issues jeopardizing project success.

You can be the first person that initiates the pre-meeting. You can make every one feel welcomed and appreciated. This sets a positive tone for the meeting. If you open the meeting whinning...you set the tone for continued complaining.

Randy Pausch calls this the Eeyore/Tigger meter. Think of a meter of 180 degrees. From 0 to 90 is Eeyore. He represents the chronic complainers and whiners. From 91 to 180 is Tigger. He represents the positive attitude person. Eeyore side is red. Tigger side is Bright Yellow.

Take it upn yourself to set the tone. Always set it at about 1/2 way up the Tigger side of the meter (about 135 degrees) . By doing so, you will gain more positive thoughts and ideas from the meeting. Even the nay-sayers or complaining business users will be pulled up from the Eyore level.

To quote Winnie The Pooh: Just because an animal is large, it doesn't mean he doesn't want kindness; however big Tigger seems to be, remember that he wants as much kindness as Roo.”

My challenge to you is to be at least 135 degrees (1/2 up the Tigger side) with EVERY confersation you have with anyone. Do so for one month. You will be amazed at the positive difference it will have on your life (including your career). It is NOT easy. If you fall at all or fail to do so in every conversation, start the meter over and go for one full month.

I'm never crazed the day before vacation. I know at the beginning of the week (or fi ve b usiness days before I leave) what I need and can possible accomplish before I leave. I make lists. I make a list of what HAS to be done before I leave. If I do not accomplish these tasks, someone will be impacted negatively. Those are what I concentrate my efforts in completing. These are priority number ONE.

Five days before I leave on vacation, I:

1. Make the list of priority items. Put them in what I think is the most important. Determine what has to be done in order for someone else to perform their work while I'm away.
2. Alert business users I'm currently working with about my schedule (what will get done and what may get done and what won't). I verify the top ONE thing they need done by me or by the next person in line to work on something while I'm away. I always provide the name, telephone number, and email of the person to contact during my absense and who will be working on the task in my absense.
3. Alert anyone that is depending on me to get something done for them over the next two to three weeks (or one week after I return). I verify the top one thing they need and negotiate wnything that is in conflict with the business community.
4. Keep ALL phone calls and emails friendly but SHORT AND TO THE POINT. No on-going discussions. This is not the time to tell stories. It's easy to politely say, "Hey, I've got a lot to get done so let me catch up with you when I return."
5. Oh, I check emails maximum 4 times a day.

The day before I leave for vacation:

1. I TURN OFF IM!
2. I make a liust of what has to be done upon my return (drain my brain so I can enjoy the trip).
3. I write a quick status on wehre everything stands for coworkers, management, and the business community.
4. I talk to everyone that needs to get something done in my absence. Reminding them of the importance and encouraging them to complete (discussing the implications if they don't).
5. I send one more email to all about who to contact in my absence.

It's funny. I actually follow this process every week. I'm focused and organized on what has to get done. Maybe that is why the day before vacation is just like any other day. No feeling of rushed. When things do pop up (hey gremlins are always fed after midnight), I compare that to the priority list to see where it fits. Being organized and adaptable relieves the day before vacation stress.

OK, let me go and finish the other two priority things to gete done this morning. I'll blog with you later.

From a technicians point of view, I also enjoyed the book. I enjoy any book that makes me think. This book made me think of other ways blogs would be valuable to the business and IT "inherit friction." Because of this book, I'm testing my theory. I love books that spark ideas!

The book also mentions some excellent examples and refers often to Purple Cow (Seth Godin...a personal favorite author of mine). This book was written before Meatball Sundae which is my favorite Godin book at the point in time.

A book for "how to" start your own blog (and all the other tweaks to get into search engines), I prefer the book Blogging for Business by Shel Holtz and Ted Demopoulos. This book I would keep on the bookshelf as a reference book to blogging.

Blogs open communication. It invites discussion. A project-focused blog could open discussions around scope and requirements. In that scenario, it would be an Internal blog which would invoke business participation. Business, therefore, would be engaged.

Blogs that provide insight into the workings of Information Technology and its staff might not initiate much discussion. I ponder then, would blogs be the proper venue? My initial answer is "yes." I hope to provide proof through the other blog.

I came to this conclusion because I read many blogs regularly (business, stocks, news, politics). I do not contribute to any of them. I do, sometimes, act upon them or form opinions based upon what I read. This, IMHO, is why IT departments need to have a blog geared towards a business users audience. It provides insight and direct contact with the Information Technology group on how things are built. It provides credibility into those that write for the blog. It provides an avenue of open communication even if no business user participates.

Business and IT relationships are strained. The relationship can be improved but only day by day. An IT blog targeted to the business community, I believe, is one way to build a better relationship with the business community.

My goal will be to have the business community get to know the technology community. Let them see how the organization works, the information they need, and the process to deliver to the business. Let the business community understand why it takes so long and cost so much to deliver something. Let them know when they should get involved and why they should stay involved.

Before any technologist gets offended, the business community sees us as "geeks." It is how we are commonly referred to when they discuss things among themselves. Therefore, I'll call the blog: How to Communicate with Geeks. It will take me a couple of days to get it organized.

I'll update this blog with results. Feel free to comment on this post with any ideas you may have on what the business community should know when working with technologists. Keep in mind that my overall goal is to decrease the software failure rate through better commmunciation between the business and IT communities.

Yes, blogs help collaborate between individuals with “like” interests. A “like” interest could be a specific project under development. Participants become trusted friends with a common interest of the success of the project. Does that work when you have a business person and IT person without the project in common? Business and IT have different mind-sets and many times different interests. So, by having a blog, do you improve the relationship with business and IT.

With this in mind, should blogs be used to improve business and IT relationships? After reading page 91, I believe the answer is yes. A blog should be developed by either business or IT folks as a “get to know me” type blog. It would behoove IT to initiate the conversation.

Relationships are built on an emotional level. It allows for a business person to see who you are as a person. This builds trustworthiness. The famous quote by Jeffery Gitomer says it all. “All things being equal, people want to do business with their friends. All things not being so equal, people STILL want to do business with their friends.” Good business relationships have an emotional connection. They are built on a friendship level.

Blogs create long-term, sustainable word-of-mouth discussions. This is the basis of building a relationship. Relationships are not built in a day but by working at it every day. Many blogs post daily or at least weekly. If IT folks had a blog that talk about themselves; it provides a mirror into their work ethic and belief system. The business community can see how you work and your approach to different problems. Discussions between IT on technical topics can illustrate your ability to handle negative and positive critics. When a business person googles you, a blog post may come on the first page. They can read your posts and see what kind of person you are and whether they want to work with you.

Self-promotion is a bad thing in the blogworld. It is also viewed negatively by the business community. If you self-promote through your many posts, business sees that this is the kind of person you are. If you self-promote all the time, then you will be seen not as a contributor but a taker. Blogs are about showing who you are as a person. Successful blogs give value without expectation of return. That is the type of individual business wants to have work on their big projects.

To answer my own question, “do blogs help improve the business/IT relationship?” I say “yes” because it shows the type of individual you are. It provides insight for the business community when they select who they want to work with them on a project. It can only hurt if you are the kind of person that doesn’t give value first and argue for the sake of arguing. Since a business person could be just a lurker, you may never know if they read the post or not. Your post may never be read by a business person but I suspect someone will and that person will provide an opinion to the business person based on that post.

I agree, I'm chatty. I like to talk and I love to write. That is why I'm a professional speaker and a published author. This blog is another way for me to write as I would have in a personal journal. Only this time, I write for everyone to see. When I speak to audiences small and large, my aim is to "connect" with the audience. I do the same here and with my eZines. But...does that form a relationship?

Don't get me wrong. I think blogs are a great vehicle, especially for my different businesses. I also recommend in my consulting practice that companies, small and large, start blogging. Blogging brings the business closer to the customer. It helps them connect...but does it build a relationship?

Blogs can be collaborative as a team works together towards a goal. Blogs can be a means of teaching where the initiator is the teacher and those that participate are students. Blogs are really "an ongoing vehicle to share thoughts and observations" that allow participation...but, does it build a relationship? [paraphrased from pg 61 quote from Intel CEO Paul Otellini]

I'm going to ponder this a little more before I write down more thoughts. Feel free to add your comments. Understand that the scope of relationship to me surrounds the building of a relationship between IT and business. Yes, a connection can be made but is it a relationship?