• Home
• About
• Contact LÛCRUM
• Polls
• Archives
• BI Symposium Event

• Business & Leadership
• Business Intelligence
• Careers
• Featured
• LUCRUM News
• Podcast
• Technology

Subscribe

Decisions Vs. Assumptions

Today I will be rather blunt. There is a misconception about decision-making that has plagued many companies and has contributed directly to the high failure rate (or perceived failure rate) of projects.  This single point leaves us with an orientation that either directs us to success or leads us on a path to failure.  Regarding project vision, goals, objectives, benefits, scope, requirements, usage, feature set and functionality, look and feel, navigation, data, relationships, CRUD, security, quality, strategy and anything else that is not plumbing…

 

“When IT makes decisions, they are really assumptions!”

 Once we understand this point, we can really get down to setting direction and building relationships that help us (IT) drive value back through the business. Let’s look at this in more detail.

 When IT makes decisions (about the project dimensions I mentioned above), it sets off a chain reaction and these are the results.

 

1. IT owns the project. This leads to the business becoming disconnected from the process. The value that the project could have brought to the company is not realized because that disconnection exists. At the end of the day, IT ends up holding the bag because when it comes to implementation, there is no ‘real’ sponsor. Oh, there may be someone who has that role, but their real power has been usurped; and not because IT used their power for evil.  IT really wants to use their powers for good, we just try to save time. And that is the slippery slope!
2. IT ‘continues’ when they should ask.  Maybe IT thinks they know the answer. It could be that the business doesn’t know and in trying to keep the project on time, IT steps up and answers. Or simply IT wants to move things along and skips this process all together and makes decisions. Either way, IT faces extreme pressures to keep timelines and costs under control. And its hard to see the long term impact of simply making decisions and “keeping things on track”.
3. IT ‘continues’ when they should validate or verify.  Once a decision is made, it is tempting to keep that momentum.  That decision was made and no one got hurt – nothing destructive happened…so why not keep going, after all it will keep us on track and that’s what the bosses like to hear. Well, when IT makes decisions they must be validated or verified by their customer. Have you ever went in to buy shoes and they simply put a pair in the box after you explained what you were looking for? Most likely not – we need to look at it, touch it, try it on, feel how it performs, compare to other shoes and see how they bring value to you as a person.
4. IT makes a lot of progress and most of it potentially in the wrong direction.  Often times in my career I have managed what I think of as a thoroughbred. This is someone who explodes at the beginning of the project, excels throughout the middle game and ends with a sprint. They high performers are worth their weight in gold. But there is a cost. That cost comes in the form of … “Yes, you are going 120 MPH but you are headed in the wrong direction!”  I have spoken those words more than once, that’s for sure. IT must ensure that we are delivering the right things, not just right away. IT must strive for strategic value over making everyone happy. IT must validate the ASSUMPTIONS (formerly known as decisions) at well disciplined and scheduled times. 
5. Project scope creeps.  Trying to become all things to all people, IT has lead the application to a place where it actually meets no ones needs. It’s so broad that it’s too shallow to use.  It’s like having a map of Ohio in actual size!
6. Costs get out of control. Its like a nuclear bomb, you know its there and no one speaks about it for a long time. The costs keep growing and then one day…all life ceases.
7. The project is late.  But then it becomes very late, then its renamed but then its late again and so on. When IT can bring those decisions back to the customer the IT is holding a laser and can really make an impact. Alignment and focus on value leads to success.
8. The business looses trust in IT. This is where everyone looses. The company does not receive the value that they need to compete. They loose competitive edge and have to rely on their existing momentum to take them places. The business receives pressure to perform. They are hesitant to team up with IT and put their futures in the hands of a group that doesn’t deliver. The business must make progress so they take on some projects; this leads to animosity between the groups and contributes to a further disconnection. Eventually, the business ends up with a shadow IT group. This leads to a degradation of standards which impacts quality throughout the organization. And so on…

I am just scratching the surface here. But the point is that IT makes assumptions and until they are validated by the customer (or the business) then they must remain just that… Assumptions.  Its ok to make assumptions, but you can’t just leave them all over the place. Once they are made, there must be a process to convert them to decisions! This is done on many levels; from a simple phone call (and the supporting documentation appropriate to the need) to a full enterprise level governance effort where members from every line of business/functional group are represented (with a sponsor, formal charters, and a framework for interfacing with the other groups within the company).

Lastly, here is what I am not saying.  I am not saying that the customer (or the business) lead the development project. What do they know about building applications? Chances are they can not manage a project. I am sure they don’t have much visibility in to the infrastructure (data, information, application, network/hardware…) and the strategies going forward.  I am not even saying that IT makes the wrong decisions – often times they are technically right, after all, we are the technical folks, right? But how does that align strategy with value? How do we ensure that our customers are successful? … By becoming a partner (but this is another blog)! When we reach this level, communication is a two-way street. We are responsible at the fiduciary level for making assumptions and then converting them to real decisions!

Make the decision today to convert your group’s assumptions to real decisions! This is a principle that must be built within each team’s DNA. The easiest way to get there from here is to lead by example.

~ Scott Felten

Is that really a Source System?

Last week I needed to purchase a new memory card for my daughter’s digital camera.  Because I rarely go to a brick-n-mortar electronics store anymore, I headed to Amazon.com.  After a few minutes of browsing, I found exactly what I was looking for.  I added the item to my shopping cart and proceeded to checkout.  As I was entering my payment/shipping information, I realized that I wasn’t actually buying the memory card from Amazon, but rather from a reseller on the site.  No problem, I didn’t necessarily care who I got it from.   I just wanted a product that met my needs at a reasonable price.  So in this case Amazon provided the service and another vendor provided the goods.  Daughter happy = Daddy happy.

Take this scenario into our consulting world and in particular, data warehousing.  A data warehouse is a repository of data.  Data is collected from various source systems residing throughout a company’s infrastructure and integrated, consolidated, and aggregated in a meaningful manner for decision making.  The source systems provide the service, but is the data they are providing necessarily originating from them?  Maybe yes, maybe no.  Do I care?  Maybe yes, maybe no.

The purist will say that if data isn’t originated in a system, you should keep swimming upstream to the “ultimate source”.  In this fashion, you’ve reached the system of origin and life is good.  But what if this information isn’t meaningful until it is been run through the company’s legacy costing model written in a proprietary system and supported by Bob who runs “process X” twice/month and doesn’t know much more than that? 

Given today’s ever increasing pressures on delivering more value in a shorter timeframe, is it better to deliver the goods to fulfill the customer’s need or improve the service by which the goods are delivered?   It’s a balancing act of business value, effort, and time.  I’m all for improving processes.  The cleaner the process, the more maintainable it becomes.  However, my job is also to meet my customer’s expectations.  One of the biggest values in data warehousing is its ability to “Unhide Data”.  I’ve come across numerous projects that have spun their wheels in source system analysis.  Manual processes were perceived as bad and had to be improved.  The timeline for delivery didn’t change, as a result, later phases (design, development, and oh my gosh testing!) just shortened.  Was that good time spent?  In most cases, the final answers came back as “leave the source alone, it’s working”.  Hours/days were lost and now the team had to work harder and longer with greater stress to meet deadlines.  Because of this, I would rather deliver solutions in multiple phases.  The first phase delivers the quick value (no need to look at the man behind the curtain).  Subsequent phases can look into the feasibility of streamlining manual processes and/or swimming past the legacy costing model.  Choose your battles and move on.

So which is it, give me the service or give me the product?  The answer is both…just give me a solution that delivers it.

Dave

Measuring Success

So what does it mean to measure? Webster’s says to measure is “the act or process of ascertaining the extent, dimensions, or quantity of something; any standard of comparison, estimation, or judgment.”

One of the first lessons I learned during my career at P&G was “You get what you measure!” In other words, unless you’re tracking the activities that drive your business, you won’t know how you’re doing. Is the business healthy or not? In LÛCRUM’s Delivery Organization we’ve been focused on measuring a several key areas of our business over the last year. I’ll focus on 2 key measures – consultant utilization and engagement health.

Consultant utilization is key to our business health since our revenue is dependent on billable hours with a client. If we’re not billing hours, we’re simply not making money. Like any business, if we’re not making money, we won’t be in business very long. Not surprising, our goal is for all hours spent with a client to be billable. While there are times it’s necessary to provide ‘free’ effort, we obviously want to monitor that and ensure it’s in check. We also measure how many hours our consultants spend ‘selling.’ While selling is primarily a Business Development role, a consultant’s technical and business experience can be valuable in making a successful sales call.

Another area where consultant’s time will be spent is “developing the practice”. It’s important for us as a company to develop as individuals and to contribute to the development of the organization. Our contribution to the company might be working on an internal project or serving on a company committee. But one of coolest things I found when I joined LÛCRUM was the concept of “Geek Speak” and “Brain Brews” – technical and business training offered several times a month at lunch or after the business day. We’re each encouraged to attend as well as present to the organization. Yes, I’ve digressed from the topic of measures, but these sessions are really great!

So back to topic….On a weekly basis, the Senior Management team and the Delivery leadership spend time reviewing the overall utilization as well as drilling down to the portfolio and individual. We’ve learned a lot about how our time is spent and it’s helping drive business decision!

The other key area where I spend my time as the Quality Manager is tracking our engagement health. Key is to monitor the next ‘deliverable’ and through the use of conditional formatted ‘traffic lights’, monitor for those yellow and red light! It’s not rocket science, we’re currently doing this through an excel dashboard but it’s allowing us to see the current engagements in one view and ask ourselves questions about what’s going well or what needs attention.

While I’ve mentioned Senior Management and the Delivery leaders regarding the review of our measures, it important everyone knows and understands our Delivery measures. We recently made the information available to everyone through our Delivery Sharepoint site. This site provides weekly or monthly measure in dashboard format. In addition to utilization and engagement health, we also provide visibility to the revenue vs goal, bench, training, recruiting and years of service.

We’ve come a long way in the last year and the journey of Quality Management continues. Stay tuned…….

Expanding Your Box

My wife and I were sitting on the couch the other night and she was complaining that her sweat pants were fitting to tight and cutting into her stomach. Oh did I mention that she is seven months pregnant with our first daughter. Anyway, we were sitting there talking and she suddenly asks ‘Don’t you have sweat pants?’. I said ‘sure’ and she went off to look in the closet. One thing you should know is that even pregnant, I have still have 100+ pounds on my wife. She came back later extremely happy. She had found a pair of my sweat pants and had them pulled up over the baby bulge and fitting comfortably. She looked funny, but she didn’t care. She had solved her problem.

Why do I bring this up? My wife is one to follow her usual processes. Clothes don’t fit = go shopping. She has bought her share of materity cloths, but is becoming more concerned about saving money. She had a problem, but didn’t want to follow her normal process and go shopping. She began thinking outside her ‘box’ of solutions can came up with something that resolved her problem and saved money. (Yeah!)

When developing solutions to IT problem, it is easy to get stuck in your ‘box’ of solutions. It is easier to stay in your comfort zone and create solutions based on what you have done before rather than venturing out and trying new things. I fight with this all the time. I recently had a client that needed to add an admin page to view user account information. They did not have reporting or direct access to the database. If I add a page to the site, then I have to secure it from other users. This can quickly add up to some development time doing the standard solution. What if I extend my thinking outside my ‘box’. They have SharePoint which is used to feed list information to the web site. Why not add the view user page in SharePoint? Security is already setup and they know how to use it.

With the pace that technology and development tools are changing today, it is hard to keep up with everything. It seems like there is a ‘best new way’ of doing something each year. Don’t get comfortable in your ‘box’. Try new technologies. Think of how this new tool can be used to solve problems in place of your old way. Read articles, attend user groups and talk to other people about the new technologies. Get an idea of what they do and how they might be useful to you. You might be surprised on how well they ‘fit’ your problems and can be added comfortably to your ‘box’.

Jeff

 

A Rational Conversation With My Mechanic

I took my Suburban in to the dealer for some brake work last week. I usually drop the truck off in the evening and then have the shop call with an oral estimate and explanation. This led to a rational conversation with my mechanic.

15 months ago I replaced the rotors and pads after the brakes began shuddering pretty badly after what seemed like a short time, maybe 18 months. A Suburban is a heavy vehicle, and it carries my wife and daughters, so I like to make sure the brakes work properly. The last thing I want to do is skimp on my brakes. At the time I was told that the rotors were after-market and that is why they warped pretty quickly. Oh, and there wasn’t enough material to turn them, either, so I needed new rotors. I, in fact, did use after-market rotors, so the diagnosis seemed correct, and I let them replace the rotors. Everything was good to go.

Fast forward to last week. The brakes are again shuddering madly on the Suburban along with a number of other issues. I drop the car off. They call me the next day. We talk. I’m told the rotors are warped pretty badly. I’m thinking, “after 15 months? That’s less than where I took it last time. Why should I spend money with the dealer if performance is no better?” So we talk this through. Service tells me that the records show the pads were replaced last time, and that’s it. “Hmmmm,” I say. “I was told last time that the rotors were replaced,” and then I go into my story about after-market rotors, blah, blah. Service digs a bit and sees that the rotors were replaced, but that they were replaced with an inferior, and less expensive, of two choices. “OOOHHhhhhhhh,” I say, thinking to myself that I was not given this choice 15 months ago. I assumed service would replace the rotors with better performing ones after chiding me for choosing after-market the first time.

I could have laid into this guy and the service department in general.  I didn’t.  I was somewhat disappointed, though.  Still, in the end I got what I paid for, so it’s not like service pulled the wool over my eyes.  I wasn’t charged for high-end rotors.  It just meant that I had to bring the car in a bit earlier than I would have liked.  At this point, as the customer, I finally had all the information I needed to make better decisions.  Before I spent the extra $150, I did need to escalate.  I told service I would call them back after conferring with my account^H^H^H^H^H^H^Hwife.  She handles the money and I didn’t want to make the final call without approval   My conversation with her went as anticipated, “They cost more?  But they’ll last longer?  Sure, let’s do it.”  I called service back and said let’s do it.

This interaction with the service department doesn’t seem that much different than interactions that happen daily during IT project life-cycles.  It’s all about getting all the information, even when it can be disappointing, making rational decisions when the guys under the hood find unanticipated issues, and then getting buy-in on the solution every step of the way while communication takes place with all parties to keep everyone on the same page.

So project managers, make sure you’re communicating to your project sponsors all the information all the time so that the sponsors can make decisions.  And project sponsors, hold your teams responsible for what they’ve committed to, and when they bring you new information be ready to bend a little to make sure you get what you want.

- Andy

More Than Practice

Yesterday, my fellow colleague Jeff Morris gave a great presentation on development best practices. Since we had a small group, the presentation quickly turned into a fun and engaging discussion as we exchanged stories and thoughts.

Topics covered:

• Logging – Be sure to capture those pesky errors and handle them with style.
• Testing – Trust your code, but verify that trust.
• Comments – They are only as helpful as you make them!
• Reviews – Review the application’s functionality, logic, and code as often as possible.
• Consistency – Use templates and standards.
• Development Process – It’s important to have a method to the madness.
• Documentation – Try to make something that will stay alive.

Ignoring these practices will undoubtedly cause a lot of pain and headaches. It is also important to be realistic and remember that constraints (time, money etc…) can make following all of these practices extremely difficult.

When it comes to best practices, the list could go on and on.  Each one of these practices represent a building block for success.  In summary, creating a solid application requires solid development practices.

Next Generation of the Data Warehouse (DW 2.0)

I had coffee today with one of the authors of the new book, “DW 2.0: The Architecture for the Next Generation of Data Warehousing”, Derek Strauss.  Derek worked with William (Bill) H. Inmon and Genia Neushloss to write the book and it will be available July of this year (’08).  His company (Gavroshe) becomes the first independent consulting company certified by Bill Inmon as DW 2.0 Architects.  We talked about why DW 2.0 and what makes it different and he had some really interesting comments.

First of all, there is that big statistic that Gartner has reported…“50% of Data Warehousing will have limited acceptance or be considered failures.”  Derek commented that it’s frustrating to be in that area and to hear that statistic bantered around all the time. He challenges the premise…what is meant by the term ‘data warehouse’. After all, one man’s ODS is another’s datamart is another’s warehouse is another’s database is another’s xls sheet containing GL entries.  So, by setting a standard (DW2.0), it sets the baseline; OK now we know what a data warehouse is.

Second, they wanted to bring corrections to the DW environment. There are real issues around the traditional notion of a data warehouse. We talked about two of them at length.

Data currency – lifecycle of Data. Guess what, data has a lifecycle. Who knew? Well some of us experienced folks have known this for a while – but within the DW2.0, this notion is has a separation of concerns (to steal a SOA term).  Think about what happens over the years as data decays.  The use of an attribute changes over time as the business’ competitive landscape changes and they respond.  What happens to that data – do we declare a new attribute at some point, do we change it and push the new meaning upstream, do we just live with it?  One of the key pillars (or sectors to use Inmon’s terminology) of DW 2.0 is that the lifecycle of data is embraced.  Here is how it nets out… Refer to Figure 1 at the end of this entry.

 

• Interactive Sector- The place where high performance data warehouse processing occurs (Very current data – Transaction data)
• Integrated Sector – The place where integrated data resides (Current data – Relative to the business needs; hourly, daily, etc…)
• Near Line Sector – The place where data with a lower probability of access resides (Less than current data – Also relative to the business needs; weekly, monthly, quarterly, etc…)
• Archival Sector- The place where data with a truly low probability of access resides (Older data – We all know what goes here J)

Unstructured data – emails, documents, faxes, etc…  Traditional DWs had zero notion of unstructured data. A good analogy is the communications that occur between two people. The experts say that 80% of that communication is non-verbal and only 20% consists of the actual words we say (fun topic for another time). The same is true with data. For example…a CRM promises to give you a 360 degree view of your customer. Great, except that they forgot about the communications that we had with the customer. It’s like saying that the complete view is made with only 20% of the data.  The DW 2.0 architecture makes use of ‘probabilistic matching’ when looking at relationships between unstructured and unstructured data as well as between structured and unstructured data. Now you have a 360 degree view of you customer!

Enterprise Metadata Repository.  We did not talk much about the metadata aspect because no one really likes talking about metadata J. But, threaded throughout the architecture is the notion of metadata that has enterprise reach and natural to the data warehouse – a tight coupling.

In looking at DW 2.0, it is exciting because of the reasons outlined above. It was a struggle on several levels to have ‘one warehouse’ with no notion of data lifecycle.  On one level, it’s hard to treat data equally, when you really know that some stuff should be retired and some is volatile because it was just born.  To know that the teenaged data that behaves badly is managed in the same place, the same way as the 20/30 something data that is more mature. Also, when dealing with the finance folks, it’s easier to speak their language. No need to request money for another ODS when we already have a data warehouse…rather, we need to address the data lifecycle…data depreciation – or planning ahead; data accrual!  Once they understand that data is an assets and that assets depreciated or have a lifecycle, we can engage in conversations about how we need to manage this condition.

Of course, since DW 2.0 has separation of concern around currency – we can employ the technology that makes the best sense for that stage of the data (Oracle to handle the Interactive Sector, SQL Server to both the Integrated and Near Line Sectors, and Archiving on DB2 – just an example.)

Then leveraging emerging investments in MOSS becomes strategic to the warehouse (fodder for another day).

Lastly, since DW 2.0 has been trademarked, there will be no mistake about its composition.  Only the original authors and architects will be able to make a change.  Given the track record of these folks, I think that is a good idea. For more information on DW 2.0 visit http://inmoncif.com/home/.

In summary, DW 2.0 Advantages…

• Hold data at the lowest detail,
• Hold data to infinity (or at least to your retirement),
• Not cost huge amounts of money,
• Have integrity of data and still have online high-performance transaction processing,
• Link structured data and unstructured data,
• Tightly couple metadata to the data warehouse environment,
• Support different kinds of processing without sacrificing response time, and
• Support changes of data over time.

Take Care,

Scott Felten 2.0

 

 

 

 Figure 1 – DW 2.0 Architecture

 

 

 

 

 

 

Don’t Make Reporting Just An Afterthought

 When your faced with all the planning, designing and development involved with building a new application, reporting can just become an afterthought on the project schedule. I’ve been on many client projects where reporting is just a week slapped on the end of the project schedule. “We just need to create a few reports and we are done.” This is not true if your building a system of any size or complexity. Ask yourself why the system is being built. All that work to store data and build an interface to input the data, what is it all for? It is to create reports for the business to analyze how the company is doing. A company runs and survives on the quality (and quantity in some cases) of it’s reporting. CEO’s and business leaders rely on these reports to validate the health of the company and steer it’s direction.  Do you think they want to hear that everything they rely on was just and afterthought!

Reporting systems can get really complex when you are dealing with business people who like to ‘slice and dice’ the data. It seems like they want 20 reports to slice the data every way possible. Executives don’t want all the detail, but want everything summarized, categorized and broken out by time. Once the business hears about a new system in development, requests for specialized reports above the “10 standard report” you planned can drive development into overtime. The work loads increase, but the amount of time does not. Add on top of that the need for securing the reports based on roles, teams or other categorization. Extending your application security model to include reporting can add time to your already crunched project schedule.

 You might think that just starting work on the reporting system earlier will give you plenty of time to address the issues above. That is true, but starting reporting to early in the project schedule can cause other issues. If you start development earlier you will need to plan for reporting to take more time. SAY WHAT! If the main application and database is still in development, things are going to change. Fields are changed, flags are added, data is incomplete. All these thing effect the ability to create a correct report the first time through. As the design of the application changes, reports will need to be changed also. This takes more time and extends the reporting schedule.

 There is a positive to starting reporting early. The reports that are created can be used to help validate the system in development. I worked on one project where the business leaders kept coming to me and telling me that the reports were validating were wrong. As I analyzed the data, I found problems with the interface and/or database. Once the issues were corrected, the report was correct. Having reports to validate the system during development can be very useful, especially if you are migrating records from an old legacy system to a new system. Making sure you have all the data and you can match numbers from the old system is critical.

  

The point of this post is to get you thinking about issues around reporting that may cause delays in your project schedule. I’ve brought up a number of problems, but what can be done about them? Here are some suggestions.

• Don’t make reporting an afterthought. The reporting system can be as critical and complex as the application.
• Allow enough time in your schedule for proper requirements from business leaders. Make sure you are meeting their needs.
• Allow time to do proper architecture and design of the reporting system. Factor it into your security model design.
• Design reports that meet the business needs. A report no one reads is a waste of time.
• Combine reports where you can. Create a single report with more parameters to allow the business to ‘slice’ the data without you needing to maintain 10 copies of a report for different users.
• Write efficient code. If your using sql, spend the time to make sure it if quick and efficient. Speed counts.
• If you are replacing a legacy reporting system, make sure you analyze how the old reports where put together. You may need to match those numbers with the new system.
• Work with business leaders and executives to make sure you are providing the information they need in a format they can use. If they can read a report or two and get everything they need to know, they’ll love you for it and it will help validate the cost of your reporting effort.
• Know you data. I tell anyone who writes reports for me that they can’t write quality report if they do not know and understand the data. SQL is a language that makes it very easy to get the wrong answers.
• Validate your data. You can’t get a correct report with wrong data. Test and development systems need to have real data and lots of it.
• Set expectation with leadership. They need to understand why extra time (and money) is need to create a proper system.

 

Proper reporting can be the lifeblood of a company. Don’t make it just an afterthought.

 

Jeff

 

 

 

 

 

Certified or Certifiable?

Ok, so you’ve been around the block a few times and think you know your stuff when it comes to Microsoft technologies.  What better way to prove it than to obtain a formal certification in your field of expertise?  Well for one, where do you start?  In a sea of dizzying acronyms (MCSD, MCSA, MCITP, MCPD, MCTS, MCSE, MCDBA…), how is one to survive the turbulent waters and inherent confusion of this journey?  Better yet, how are your customers supposed to understand these 4 character “feathers in your cap” that everyone displays proudly on their resume and business cards?  Good questions…

A number of our own LÛCRUM certifiables have navigated these waters in the past and to date they are the proud recipients of 15 such certifications.

Thankfully Microsoft has taken a fresh approach at this process.  Certifications now fall under 1 of 3 categorizations.

Technology Series – This series exhibits core technology skill on a particular product/technology.  Basically nuts/bolts stuff.  Typically requires 1-3 exams.  Certifications in this series retire when Microsoft product support ceases, thus they have a limited lifetime.

Professional Series – A “step up” from the Technology Series, this series adds job roles in addition to technology competency.  It demonstrates your ability to deliver solutions within that role.  This series typically requires 1-3 exams with a Technology Series certification prerequisite.  It also requires periodic recertification.

Architect Series – The Mac Daddy of Microsoft certifications.  This series displays your business IT prowess in addition to in-depth technology acumen to deliver enterprise capable business solutions.   This involves a rigorous entry process and a formal oral review board (conducted by peers already possessing an Architect certification) at the conclusion of the certification process.  It requires periodic recertification as well.

Across all of these series, only 4 certifications remain from the previous multitude of acronym chaos.  They are Microsoft Certified Technology Specialist (MCTS), Microsoft Certified Professional Developer (MCPD), Microsoft Certified IT Professional (MCITP), and finally Microsoft Certified Architect (MCA).   Each of these certifications allows for specialization in a variety of areas, however, the certification remains consistent.   Once obtained, your branding for resumes and business cards simplifies to your certification plus specialty (i.e. MCITP – Server Administrator).

So how does one obtain these new certifications?  Depending on the series…study, study, study and perhaps practical work experience.  Microsoft has detailed all the required exams for each certification/specialty combination.  Of course a wealth of choices exists for getting you to the exam desk.  Books, webinars, study groups, classroom learning, user groups, and conferences are all viable vehicles.  Practical work experience just takes time and exposure.  As a result, certification takes time and patience and is not something done overnight.

If you’re interested in more information, check out Microsoft’s certification website… http://www.microsoft.com/learning/mcp/default.mspx

Happy learning…

Dave

LUCRUM, Meatballs, and Marketing

Yesterday I, along with the LUCRUM business development team, got the opportunity to listen in on a live conference call with author Seth Godin, courtesy of SFEntrepreneur.com. It was excellent and extremely relevant to the future of business.

Seth discussed his latest book, Meatball Sundae, which is about the revolution that is taking place in business thanks in large part to the growth and expansion of the web and other associated technologies. Seth claims that the old model for business, and thus Marketing, is broken and dying.

The old way is: big media, big advertising budgets, limited communication channels, top down, interrupt people with average, sanitized messages about average stuff made for the masses. This is the Meatball part of the Meatball Sundae and represents the old way of doing things – classical marketing and advertising.

The new way is: infinite communication through infinite channels in all directions, constantly evolving conversations, consumer oriented, niche focused, web enabled, search driven, and completely at odds with what used to work. This involves employee development, R&D, a commitment to making something remarkable, listening, problem solving, blogs, wikis, social media, word of mouth, and other emerging forms of technology in marketing. It is the Sundae – the whipped cream with a cherry that everyone wants to put on top.

The problem many companies face is that they try to keep the old (Meatballs) and then combine the new (the sundae). What you get in the end is not something great, but rather something that just does not work. A Meatball Sundae – Gross. You can’t just take the old way of doing things, slap some “new marketing” on top and expect it to work. What is needed is a whole new mindset. One that is about empowerment, accountability, open communication, transparency, honesty, and creativity.

I believe that Seth is absolutely correct in his analysis of the current state of business, and that what he says can be applied to what we are doing here at LUCRUM. When I started here at LUCRUM a few months ago, I had just read this book for the first time. I am now re-reading it. We are trying to make the leap from yesterday into the future, and as a result we are making fundamental changes to who we are as a company. It is a new mindset. A mindset that is focused on how we can make our organization one that thrives in the world of new marketing, and not how to we use the new “cool tools” to support our old structure. Our cultural and structural changes have been a widely discussed topic as of late – even making the paper (meatball). Many of these challenges are not unique to LUCRUM, but rather represent the changing world around us. Further, our recent struggles merely validate the ineffectiveness of the old way of doing things and serve as an impetus for change.

We are striving to be the best in the world at using technology to solve the business problems of our Clients. I believe that our leadership team is committed to achieving this goal. Our blog represents this change on some level, but what I hope to ensure is that I am not the architect of a giant, disgusting meatball sundae of my own. I am very encourage by the fact that I see people here embracing a mindset centered on delivering incredible results for Clients. I see a company transforming into something amazing – something far bigger than “hey we have a blog now.” Yes, the blog is amazing. Yes I am very proud of it. Yes I am fascinated by the contributions of my colleagues to this experiment in marketing. But more importantly, I am fascinated and amazed by what it represents. Our people care – all of our people. Our people have a voice – all of our people. We are focusing on giving our clients and customers a voice too – all of our customer and clients. More importantly, we want to listen to that voice. No more of the highly sanitized corporate speak that plagues IT consulting firms. Just real, honest communication. We are on a journey. We have a long way to go. Still, look how far we have already come.

Back to the book… In it, Seth does a great job of identifying 14 of the trends that are shaping the future of business. They are as follows:

1. Direct communication and commerce between producers and consumers
2. Amplification of the voice of the consumer and independent authorities
3. Need for an authentic story as the number of sources increases
4. Extremely short attention spans due to clutter
5. The Long Tail
6. Outsourcing
7. Google and the dicing of everything
8. Infinite channels of communication
9. Direct communication and commerce between consumers and consumers
10. The shifts in scarcity and abundance
11. The triumph of big ideas
12. The shift from “how many” to “who”
13. The wealthy are like us
14. New Gatekeepers, No Gatekeeper

If you want to know what is driving the thought process of our Marketing, simply study these trends (or just read Seth’s blog). We will look to embrace these ideas wherever and whenever possible as we shape the future of LUCRUM. Everything we do is marketing, and thus everyone gets the opportunity to take part.

Thanks to Seth Godin and SFentrepreneur.com for putting the call together.

Live Call with Seth Godin Presented by SFentrepreneur (April 9th) by SFentrepreneur | Connecting the Entrepreneurship Community in San Francisco Bay Area, Silicon Valley, San Jose and Oakland

« Previous Page — Next Page »

Recent Comments

• 4DIQ on How Necessary is a Data Warehouse?
• Burak Guner on How Necessary is a Data Warehouse?
• Burak Guner on How Necessary is a Data Warehouse?
• Decision Factor on How Necessary is a Data Warehouse?
• LÛCRUM Inc on How Necessary is a Data Warehouse?

Categories

• Business & Leadership
• Business Intelligence
• Careers
• Featured
• LUCRUM News
• Podcast
• Technology

Copyright © 2010 LUCRUM, Inc. 7755 Montgomery Rd, Suite 160, Cincinnati, Ohio 45236 TheFutureValueofBusiness.com