This is really yet another post about how important it is to focus on the right things. I have been involved in many discussions with peers lately, and many seem to be focused on what I believe to be at best secondary concerns and at worst dangerous distractions (see my previous post on architecture). Here's a story, unrelated to the world of business, that is a pretty good illustration of my point;
The Rocks!
A few years ago I had the pleasure of attending a winter driving school in the New Hampshire White Mountains. We went through many exercises, from skid control, accident avoidance, braking on ice, you name it. The final stages were some relatively high speed runs on forest logging roads. One of the things the instructors stressed during the early classroom sessions was to focus on where you want the car to go. They said near the end of the class the would show us some things that would prove how important this was.
On the last break of the class, they took us for a walk out to the forest road, with some shovels, and knocked down some of the fluffy snowbanks along the edge of the road. During all our runs, no one had gone off road on the forest course, and it turned out to be a good thing, as under the soft stuff was an almost unbroken wall of granite boulders! They said they purposely covered them with snow, because if we could see the rocks, we would hit the rocks, as that is where our focus would be. This was something they learned over years of teaching these classes, and was not the way they started out. To further illustrate the point, we walked back to the skid pad circle, a place where several people had gone off over the course of the two days. As it turns out, of the 11 cars we put into the snow bank, all but one of them was right in front of a large tree that could be seen over the bank. we would come around the circle, see the giant tree, focus on it, and head right for it.
The point of the story is that you'll get what you focus on, which may not be what you really wanted in the first place. In our wonderful world of IT, there are a lot of things getting focus these days, but not all that many of them are adding value to our businesses.
Friday, November 19, 2010
Tuesday, August 10, 2010
Small Company Thinking - the art af being "Folksy"
My last company was small by most standards; about $40mil in annual revenue. We had been struggling, and were eventually purchased by a private equity firm. Of course private equity does not usually buy healthy companies, they buy sick ones and fix them, or dissect them and divest of the assets if the numbers are in favor of that. We were lucky in that our owners brought in a new CEO that was a real sales guy, and knew that the key to success was a true focus on the customer. Seems obvious, but so few companies truly get it.
To make the long story short, we had great success fixing the company, and it was eventually sold to a very large software company. As is often the case, we were culturally at odds with the new company. They were very internally focused, much more concerned with the proper paperwork being completed than with doing what was right for the customer. Very heavy process centric approach to everything. We were often scoffed at, with our "small company thinking" approach to things, and were repeatedly told "that is great, but it would never work in a big company".
As an example; I used to do lab tours for visiting potential customers. Deal win rate when getting the customer to visit and take a tour was near 90%. Within days of the acquisition close, this stopped. When I questioned a visiting exec as to why we no longer did customer visits, given the high win rate, I was told "That just wouldn't scale. If all of our sales teams sent every prospect here, you would be completely overwhelmed". True I said, but we went from three per week to zero, and we could easily support five. If we had more requests than that, we would figure it out, maybe tape it and use video for the smaller deals. "Small company thinking" says he. Nonsense. An excuse from big a process guy for not taking action.
When I arrived in my current position I was part of the management team brought in to help turn the company around. Yes, we have the same private equity owners (see a trend?). This company was bigger than our last success, by about eight times in revenue, and maybe four times in number of employees. As we started making changes, and refocusing the company on our customers, we heard much of the same thing; "That may have worked at a small company, but it will never work here".
Ha! It has worked. And not just as it relates to IT stuff, but everywhere in the business. It is harder to make it work in a larger company, and it is critically dependent on having the right people, particularly in the leadership roles, but it is very effective when it does work. We now find ourselves operating as a more or less independent division of a much larger company, though still under the same private equity ownership. Our larger siblings have called us "Folksy", saying that the way we do stuff works in a little company like ours, but big sophisticated companies do it their way (which usually means with an army of consultants).
To all of you that run "folksy" business, please keep it up. It works, and the folksy businesses are much more fun to work at and to do business with.
To make the long story short, we had great success fixing the company, and it was eventually sold to a very large software company. As is often the case, we were culturally at odds with the new company. They were very internally focused, much more concerned with the proper paperwork being completed than with doing what was right for the customer. Very heavy process centric approach to everything. We were often scoffed at, with our "small company thinking" approach to things, and were repeatedly told "that is great, but it would never work in a big company".
As an example; I used to do lab tours for visiting potential customers. Deal win rate when getting the customer to visit and take a tour was near 90%. Within days of the acquisition close, this stopped. When I questioned a visiting exec as to why we no longer did customer visits, given the high win rate, I was told "That just wouldn't scale. If all of our sales teams sent every prospect here, you would be completely overwhelmed". True I said, but we went from three per week to zero, and we could easily support five. If we had more requests than that, we would figure it out, maybe tape it and use video for the smaller deals. "Small company thinking" says he. Nonsense. An excuse from big a process guy for not taking action.
When I arrived in my current position I was part of the management team brought in to help turn the company around. Yes, we have the same private equity owners (see a trend?). This company was bigger than our last success, by about eight times in revenue, and maybe four times in number of employees. As we started making changes, and refocusing the company on our customers, we heard much of the same thing; "That may have worked at a small company, but it will never work here".
Ha! It has worked. And not just as it relates to IT stuff, but everywhere in the business. It is harder to make it work in a larger company, and it is critically dependent on having the right people, particularly in the leadership roles, but it is very effective when it does work. We now find ourselves operating as a more or less independent division of a much larger company, though still under the same private equity ownership. Our larger siblings have called us "Folksy", saying that the way we do stuff works in a little company like ours, but big sophisticated companies do it their way (which usually means with an army of consultants).
To all of you that run "folksy" business, please keep it up. It works, and the folksy businesses are much more fun to work at and to do business with.
Sunday, August 1, 2010
IT Rocks! - Part Two, a collection a silly sayings
In reality, some of them may be a bit corny, but they all have real meaning in the context of getting IT to rock. the first, and most important, is "There is nothing more important than our customers". This is how we run the entire company. Of course in IT, we have lots of different customers including external customers (the most important ones, as they keep us in business), partners, and the rest of our internal folks. This sounds so simple, but so many organizations miss it completely. We really take this literally. Any of our customers, whether external or internal, come before any of our own IT priorities. Our help desk tool offers self service to our users, but contrary to the way most folks view self-service tools, the goal of this is not to deflect human contact, it is to let folks interact with us in the way they choose. We encourage our help desk folks to call, or better yet, go see their customers when they work on tickets for them. Think about it, how nice would it be to see a smiling face show up at your cube; "Hi Bill, I'm Don from the IT service desk. I am just checking in to see if you are all set with your mail issue"? At the last place I worked, this would have caused heart attacks. They actually did not have the help desk folks listed in the corporate directory, purposely so you couldn't call them up. No wonder they were universally despised.
Another saying; "Try it, fix it, try it". This sums up our approach for continuous improvement, and also for our iterative approach to adding value to the business. We are not big on grandiose plans that take many months to execute. Business is too fast these days for that. We need to quickly add value, and evolve it over time. This one is also kind of a cousin to "I reserve the right to be smarter tomorrow than I am today", which really means we are not tied to a decision, and can change our minds to adapt quickly to a changing environment. Those that can't adapt will get left behind.
Next, we have "Don't let the perfect be the enemy of the good". Sometimes when working to solve a problem for the business, we can envision a beautifully elegant solution, and the only problem is that it really can't be delivered in pieces, so it would be months before the business saw any value. This is actually one my developers struggle with, as they would sometimes like to build the "big thing". The reality is that we can often do something simple that solves 80% of the problem very quickly.While this may be only good, it is often good enough for the business, and they are delighted with the speed of delivery.
The last of my sayings for today, is "Saving money won't get you good IT, but good IT will save you money". This is really about focus. Be careful what you decide your organization is going to focus on, you just might get it. See my rant on Enterprise Architecture. If you loose your focus on the business, and shift it to Architecture, budget reduction ITIL, etc., that is what you'll get, an ITIL shop with great architecture, with barely enough funding to stay alive, and still be hated (and I do not think that is too strong) by the business. By focusing on what was important (Customers First, Enable the Business, and Showcase our Products), we became a valued partner to the business, with a seat at the executive table (I report to the CEO). In the process, because we stopped doing stuff that was not important, we have reduced our spend by just shy of 20% over the last two years (while doing and SAP upgrade, I will add).
I'm sure there are more sayings we use, and I'll try to remember to write them down for another silly sayings post.
Another saying; "Try it, fix it, try it". This sums up our approach for continuous improvement, and also for our iterative approach to adding value to the business. We are not big on grandiose plans that take many months to execute. Business is too fast these days for that. We need to quickly add value, and evolve it over time. This one is also kind of a cousin to "I reserve the right to be smarter tomorrow than I am today", which really means we are not tied to a decision, and can change our minds to adapt quickly to a changing environment. Those that can't adapt will get left behind.
Next, we have "Don't let the perfect be the enemy of the good". Sometimes when working to solve a problem for the business, we can envision a beautifully elegant solution, and the only problem is that it really can't be delivered in pieces, so it would be months before the business saw any value. This is actually one my developers struggle with, as they would sometimes like to build the "big thing". The reality is that we can often do something simple that solves 80% of the problem very quickly.While this may be only good, it is often good enough for the business, and they are delighted with the speed of delivery.
The last of my sayings for today, is "Saving money won't get you good IT, but good IT will save you money". This is really about focus. Be careful what you decide your organization is going to focus on, you just might get it. See my rant on Enterprise Architecture. If you loose your focus on the business, and shift it to Architecture, budget reduction ITIL, etc., that is what you'll get, an ITIL shop with great architecture, with barely enough funding to stay alive, and still be hated (and I do not think that is too strong) by the business. By focusing on what was important (Customers First, Enable the Business, and Showcase our Products), we became a valued partner to the business, with a seat at the executive table (I report to the CEO). In the process, because we stopped doing stuff that was not important, we have reduced our spend by just shy of 20% over the last two years (while doing and SAP upgrade, I will add).
I'm sure there are more sayings we use, and I'll try to remember to write them down for another silly sayings post.
Friday, July 30, 2010
IT Rocks! - Part One
This is kind of a longer rant, so I'll break it up. Given my somewhat unconventional approach to IT, it is probably not surprising that I wasn't always an IT guy. I have really had several careers, and those experiences, plus a couple of strong mentors along the way have formed my approach. More or less in order, I spent eight years in the US Navy (Submarines), three years in commercial nuclear power, three years as a small business owner, two years writing technology sales proposals, and 12 years in software quality.
At the last place I worked (by acquisition, not by choice), the IT group was horrible. They we not the least bit interested in helping the business move forward. All they cared about was compliance with their policy and procedures. Those procedures were often at odds with the needs of the business, and even though I would find folks in the IT group that agreed with me ("You're right, it is stupid") no one was ever willing to work to change the rules. This was quite the shock, as prior to being acquired, we had an IT group that was pretty supportive of the business.
I was senior enough to have contact with enough of the executive team to know that I wasn't the only one that thought IT sucked, but that it was a common perception. The thing that struck me as odd, was that everyone seemed to believe that you had to live with it, and that big corporate IT just sucked by its very nature, and that all you could do was squeeze their budgets so at least you could pay the minimum for their suckiness.
I was convinced that IT could be done better. It was my belief that if the business felt they were getting good value for their $, you wouldn't be getting squeezed at budget time. Hence, the IT Rocks! theory of IT management was born.
The first day I had responsibility for IT here, I met with my ops director, and talked about how I wanted to approach our delivery. In that first meeting I had two things I wanted to start on right away. First, my new, single metric, if you can call it that, by which I was going to judge the team, was customer satisfaction. How I would measure it, was simple; if I asked any employee in the company, from the CEO on down "How's IT?", the target answer was "IT Rocks!". Minimal acceptable was "They are pretty good". The second thing, and the most important thing in achieving the first, was to stop saying no. No matter what the request, if we thought the answer had to be no, I wanted a good analysis of why, and if it was just because of some policy of ours, I wanted justification of that policy. I even went as far as to say that the only person in IT that could say "no" to a request, was me.
The ops director came just short of laughing at me. It could best describe it as a strong mirthful grin. He said I was nuts, and that he would play it my way, but seeing that I was his fifth boss in three years, this too would pass. As I have related this story to some of my peer CIOs, many have said that that approach can't possibly work. How on earth can the CIO review every request? The reality is that I don't think I even had to review one in the first six months. It was obvious to the team that I wanted them to say yes, so they spent a lot more time understanding what our customers really wanted, that is the problem they were trying to solve when they made the request, and then offered alternative solutions that we could do, instead of jumping straight to "no".
I'll exapand on this more about how it has evolved over the last four years, but the bottom line is that it works. IT does rock. The business loves us. I do not have to fight for budget (there is an interesting budget side effect of IT Rocks that we'll talk about later). Not only does the business love us, but we have added real value, streamlining systems and process to drive more revenue and greater operational efficiency.
At the last place I worked (by acquisition, not by choice), the IT group was horrible. They we not the least bit interested in helping the business move forward. All they cared about was compliance with their policy and procedures. Those procedures were often at odds with the needs of the business, and even though I would find folks in the IT group that agreed with me ("You're right, it is stupid") no one was ever willing to work to change the rules. This was quite the shock, as prior to being acquired, we had an IT group that was pretty supportive of the business.
I was senior enough to have contact with enough of the executive team to know that I wasn't the only one that thought IT sucked, but that it was a common perception. The thing that struck me as odd, was that everyone seemed to believe that you had to live with it, and that big corporate IT just sucked by its very nature, and that all you could do was squeeze their budgets so at least you could pay the minimum for their suckiness.
I was convinced that IT could be done better. It was my belief that if the business felt they were getting good value for their $, you wouldn't be getting squeezed at budget time. Hence, the IT Rocks! theory of IT management was born.
The first day I had responsibility for IT here, I met with my ops director, and talked about how I wanted to approach our delivery. In that first meeting I had two things I wanted to start on right away. First, my new, single metric, if you can call it that, by which I was going to judge the team, was customer satisfaction. How I would measure it, was simple; if I asked any employee in the company, from the CEO on down "How's IT?", the target answer was "IT Rocks!". Minimal acceptable was "They are pretty good". The second thing, and the most important thing in achieving the first, was to stop saying no. No matter what the request, if we thought the answer had to be no, I wanted a good analysis of why, and if it was just because of some policy of ours, I wanted justification of that policy. I even went as far as to say that the only person in IT that could say "no" to a request, was me.
The ops director came just short of laughing at me. It could best describe it as a strong mirthful grin. He said I was nuts, and that he would play it my way, but seeing that I was his fifth boss in three years, this too would pass. As I have related this story to some of my peer CIOs, many have said that that approach can't possibly work. How on earth can the CIO review every request? The reality is that I don't think I even had to review one in the first six months. It was obvious to the team that I wanted them to say yes, so they spent a lot more time understanding what our customers really wanted, that is the problem they were trying to solve when they made the request, and then offered alternative solutions that we could do, instead of jumping straight to "no".
I'll exapand on this more about how it has evolved over the last four years, but the bottom line is that it works. IT does rock. The business loves us. I do not have to fight for budget (there is an interesting budget side effect of IT Rocks that we'll talk about later). Not only does the business love us, but we have added real value, streamlining systems and process to drive more revenue and greater operational efficiency.
Wednesday, July 28, 2010
What does a good enterprise architecture get you?
Why, a good enterprise architecture, of course. Never mind that a good architecture is no guarantee that your IT environment will have any relevance at all to the business.
I presented at a recent CIO conference on our use of cloud computing, and the first slide in my presentation was a high-level drawing of our IT architecture. This one slide ended up in a discussion that lasted nearly my entire allotted time slot.
It started with the question "Wow, great architecture, how did you come up with it?"
I had to stop and think, as the reality is that I (we) didn't spend a minute thinking about or talking about architecture. We knew our existing systems were not doing a good job of supporting the business, and we started there. Of course for us to support the business, we had to understand it, and we kicked off a project (really driven by the CEO) we called TLC (Think Like a Customer). The goal was to look at the most macro of business processes, in our case lead-to-cash, analyze current state, and make changes in process and systems to streamline the business. In short, to make it easier to do business with us, for customers, partners, and employees.
Out of TLC came about 70 "quick wins"; small changes to process or systems that would make things easier for all. The key component here is that we not only identified them, we actually implemented most of them. We also identified some major gaps in process and systems, and set out to fix the business pain. Our cool architecture is the result. It is not a cool architecture because we set out to design it that way, it is because we set out to solve the business problem(s), and the architecture evolved.
I was asked by one of the attendees at the conference what my enterprise architects thought about the build it as you go approach, and I said that was easy, I don't have anyone doing "architecture" as their primary job. Certainly as things evolved we would ask the "how does this plug in" question, but our focus is always on solving the business problem which is #2 on my guiding principles of IT.
Which kind of leads me to those principles, which drive everything my IT group does:
Customers First
Enable the Business
Showcase our Products (we are an IT supplier)
If everything you do is around one of these things, you can't go wrong. Focus on architecture, or anything else not directly related to one of the principles, and you may succeed, but are just as likely to end up with a cool architecture, and still end up like so many IT departments, despised by a business that sees little value in the services you provide.
I presented at a recent CIO conference on our use of cloud computing, and the first slide in my presentation was a high-level drawing of our IT architecture. This one slide ended up in a discussion that lasted nearly my entire allotted time slot.
It started with the question "Wow, great architecture, how did you come up with it?"
I had to stop and think, as the reality is that I (we) didn't spend a minute thinking about or talking about architecture. We knew our existing systems were not doing a good job of supporting the business, and we started there. Of course for us to support the business, we had to understand it, and we kicked off a project (really driven by the CEO) we called TLC (Think Like a Customer). The goal was to look at the most macro of business processes, in our case lead-to-cash, analyze current state, and make changes in process and systems to streamline the business. In short, to make it easier to do business with us, for customers, partners, and employees.
Out of TLC came about 70 "quick wins"; small changes to process or systems that would make things easier for all. The key component here is that we not only identified them, we actually implemented most of them. We also identified some major gaps in process and systems, and set out to fix the business pain. Our cool architecture is the result. It is not a cool architecture because we set out to design it that way, it is because we set out to solve the business problem(s), and the architecture evolved.
I was asked by one of the attendees at the conference what my enterprise architects thought about the build it as you go approach, and I said that was easy, I don't have anyone doing "architecture" as their primary job. Certainly as things evolved we would ask the "how does this plug in" question, but our focus is always on solving the business problem which is #2 on my guiding principles of IT.
Which kind of leads me to those principles, which drive everything my IT group does:
Customers First
Enable the Business
Showcase our Products (we are an IT supplier)
If everything you do is around one of these things, you can't go wrong. Focus on architecture, or anything else not directly related to one of the principles, and you may succeed, but are just as likely to end up with a cool architecture, and still end up like so many IT departments, despised by a business that sees little value in the services you provide.
Saturday, March 20, 2010
We be Chatting (or is it Chattering?)
So we may have just turned on what will finally be really useful social media in the workplace.
Thursday evening we turned on SalesForce.com's new "Chatter" collaboration tool. Maybe I should say pre-new, as we were able to convince the nice folks at SFDC to turn on the beta in our production environment. I didn't want to make too big of a production of it, after all, this is supposed to be social media for the enterprise, if the users like it, they'll figure out how to make it go. It is pretty simple, even dinosaurs like myself were chatting in no time.
We did make a simple announcement so folks were not wondering what this new thing at the top of the page was, and we gave them links to the intro videos. Other than that, we just turned it loose. I have been watching closely, and there does seem to be considerable activity considering it is so new. We had a few folks asking for something like this, and there appears to have been some pent up demand. I did figure the youngsters would like it, as it does look an awful lot like facebook.
Of course the real magic here, that makes it light-years ahead of Yammer and the like, is that the SFDC objects (Contacts, Accounts, Opportunities, etc.) can participate in the news feeds. Even custom objects can play along. We have a custom project tracking application, and the projects where I am the executive sponsor will not chat to my newsfeed when something important on them changes. Pretty slick.
We did find a certain amount of humor in the email it sends when you follow someone; "Dan Petlon is now following you" is enough to scare anyone. That, plus a link to your SFDC profile is all it sends. We are calling it "Chatter Stalking"
Of course I already have my wish list:
I'll post an update as we chat on.
Thursday evening we turned on SalesForce.com's new "Chatter" collaboration tool. Maybe I should say pre-new, as we were able to convince the nice folks at SFDC to turn on the beta in our production environment. I didn't want to make too big of a production of it, after all, this is supposed to be social media for the enterprise, if the users like it, they'll figure out how to make it go. It is pretty simple, even dinosaurs like myself were chatting in no time.
We did make a simple announcement so folks were not wondering what this new thing at the top of the page was, and we gave them links to the intro videos. Other than that, we just turned it loose. I have been watching closely, and there does seem to be considerable activity considering it is so new. We had a few folks asking for something like this, and there appears to have been some pent up demand. I did figure the youngsters would like it, as it does look an awful lot like facebook.
Of course the real magic here, that makes it light-years ahead of Yammer and the like, is that the SFDC objects (Contacts, Accounts, Opportunities, etc.) can participate in the news feeds. Even custom objects can play along. We have a custom project tracking application, and the projects where I am the executive sponsor will not chat to my newsfeed when something important on them changes. Pretty slick.
We did find a certain amount of humor in the email it sends when you follow someone; "Dan Petlon is now following you" is enough to scare anyone. That, plus a link to your SFDC profile is all it sends. We are calling it "Chatter Stalking"
Of course I already have my wish list:
- I want rules-based auto-following. for example, I automatically want to follow any new project that I am the sponsor for. The sales leads want to follow new opportunities in there territories. You get the idea.
- I want to be able to start following from my iPhone.
- I really need to be able to control the colors in the new UI theme. I like the default, but I have had a good number of complaints.
- How about a "Chatter Genius"? Punch a button and see chats similar to mine, or to those of folks I follow. I would think this would be a pretty good way to find folks with stuff to say that matters to me.
I'll post an update as we chat on.
Tuesday, March 2, 2010
Our first baby steps into cloud-based application deveolpment
I attended a Salesforce.com CIO council meeting about a year ago, and came back pretty jazzed up to move some of our stuff to "the cloud". We did a pretty deep dive on what would have been the heavy hitter $-wise, and looked at moving from Exchange to Google Apps. We had a Google partner come in to discuss it. What I was hoping for was that as we brought up concerns, the partner would say "yep, we saw that at company X, and here is how we addressed it". What we got instead was, "yep, that is an issue". The bottom line was that Google Apps is just not ready to meet the needs of the power Exchange users.
Once I recovered from that blow to my cloud enthusiasm, we looked for other things to do, namely build some of our business applications on the force.com platform. I was considerably more tentative in my approach this time, but unless we tried it, how would we know if it had a place in our application landscape.
One of our challenges in taking these first steps was the cost of doing it. We have a very stable and modern in-house infrastructure. Many of the things the SFDC folks will site as to why app development is less costly on their platform do not apply to us. I have a virtualized environment, so I don't think about buying new hardware every time I need to spin up a new app. I have an established security model. Ditto for our way to approach the database. I already use an agile development methodology. I have a highly-skilled .net development team.
We still wanted to try it, and after struggling through putting a contract together with SFDC that made sense for us, we are finally dipping our toes in the force.com waters. We have two applications in production at this point. One that does very simple high-level project management, and another to manage our IT change management process.
Would I declare success? Sort of. I think I would borrow a term from our friends at Gartner and call our experience to date promising. There are limitations to the data models on the force platform. You can code your way around them, but if I have to write a lot of code, I could just do it in .net, and it would fit in with the rest of our stuff.
On the positive note, for simple stuff like the two apps I mentioned here, it is hard to beat. The change management app I built myself (and you thought VPs were useless). It took about an hour to get the basic shell and a few workflows done, and another couple of hours of tweaking once the users go hold of it. It is hard to argue with that kind of success - built by the business owner without sucking up development resources.
We have several other projects queued up; a test case/execution management app for our QA team, expense reporting, internal purchase requisitions, to name a few. So far we have just built apps for the IT department. I'll be ready to declare success when we have deployed an app (and yes, it actually has to meet a business need) to a much larger audience.
Once I recovered from that blow to my cloud enthusiasm, we looked for other things to do, namely build some of our business applications on the force.com platform. I was considerably more tentative in my approach this time, but unless we tried it, how would we know if it had a place in our application landscape.
One of our challenges in taking these first steps was the cost of doing it. We have a very stable and modern in-house infrastructure. Many of the things the SFDC folks will site as to why app development is less costly on their platform do not apply to us. I have a virtualized environment, so I don't think about buying new hardware every time I need to spin up a new app. I have an established security model. Ditto for our way to approach the database. I already use an agile development methodology. I have a highly-skilled .net development team.
We still wanted to try it, and after struggling through putting a contract together with SFDC that made sense for us, we are finally dipping our toes in the force.com waters. We have two applications in production at this point. One that does very simple high-level project management, and another to manage our IT change management process.
Would I declare success? Sort of. I think I would borrow a term from our friends at Gartner and call our experience to date promising. There are limitations to the data models on the force platform. You can code your way around them, but if I have to write a lot of code, I could just do it in .net, and it would fit in with the rest of our stuff.
On the positive note, for simple stuff like the two apps I mentioned here, it is hard to beat. The change management app I built myself (and you thought VPs were useless). It took about an hour to get the basic shell and a few workflows done, and another couple of hours of tweaking once the users go hold of it. It is hard to argue with that kind of success - built by the business owner without sucking up development resources.
We have several other projects queued up; a test case/execution management app for our QA team, expense reporting, internal purchase requisitions, to name a few. So far we have just built apps for the IT department. I'll be ready to declare success when we have deployed an app (and yes, it actually has to meet a business need) to a much larger audience.
Thursday, February 25, 2010
Be careful what you say
I was interviewed for an article in Information Week a few weeks ago, The article was published yesterday. One of my quotes in the article caused some mild embarrassment. here it is:
“So we were looking for easy-to-use BI tool, knowing the GM for our division is very good with spreadsheets—he really likes to get in there and slice and dice the numbers—but also knowing that the tool needs to be simple enough for our sales guys to use easily and quickly.”
This was one of those good thing/bad thing quotes. Good because it makes my boss sound like a spreadsheet genius, and bad because it sounds like the sales folks don't know how to drive a spreadsheet.
I got a few calls. Some accusing me of being a shameless suck-up (I am), and others from sales folks volunteering to do spreadsheet work for me.
The full article can be found here.
“So we were looking for easy-to-use BI tool, knowing the GM for our division is very good with spreadsheets—he really likes to get in there and slice and dice the numbers—but also knowing that the tool needs to be simple enough for our sales guys to use easily and quickly.”
This was one of those good thing/bad thing quotes. Good because it makes my boss sound like a spreadsheet genius, and bad because it sounds like the sales folks don't know how to drive a spreadsheet.
I got a few calls. Some accusing me of being a shameless suck-up (I am), and others from sales folks volunteering to do spreadsheet work for me.
The full article can be found here.
How do I take the "social" out of social media?
As an IT leader, I am getting more and more demands from the business for us to embrace social media. While I personally don't quite get it, I am trying to embrace it and find the business value. Our marketing folks tell me we have seen real results from our presence on twitter, but I find it hard to weed through the acres of "social" posts to find the valuable gems. I know they are out there, and have found a few. I am not sure they were worth the time I had to spend weeding through the days wardrobe, breakfast menus, etc. to find them. Once I find them, of course the gems are not really on twitter, just the links to them.
I found a few interesting folks that don't post a constant stream of mindless personal info (I am starting to think of it as social diarrhea). and will follow them and see if start to understand the value a bit more. I do think this is the key, for social media to be embraced by business, it must be relevant, and that requires some self discipline on the part of the posters.
This blog will be my attempt to capture my random thoughts on various topics. It is solely for my amusement, and for me to have a place to post something that may be of interest to others that can't possibly be done in a tweet.
I found a few interesting folks that don't post a constant stream of mindless personal info (I am starting to think of it as social diarrhea). and will follow them and see if start to understand the value a bit more. I do think this is the key, for social media to be embraced by business, it must be relevant, and that requires some self discipline on the part of the posters.
This blog will be my attempt to capture my random thoughts on various topics. It is solely for my amusement, and for me to have a place to post something that may be of interest to others that can't possibly be done in a tweet.
Subscribe to:
Posts (Atom)
