SheeleyTech

Promoted to Project Micromanager

2008-01-17T21:41:00.000-05:00

Unless you started your career as a project manager, you most likely have to work your way into the position. You probably had a highly technical role as a software engineer or maybe a systems engineer. Whatever your role was, you were the person actually doing the technical work. In my world, the world of software development, many software engineers find themselves being asked to take the role of project manager.

First let's understand why you, an engineer, have been asked to take on the role of project manager. You have probably gained a reputation of being organized. You write solid high-quality code that passes all requirements. Your design documents are well written. You stay current with the latest technologies and methods of software engineering and you know when to apply them. You are known for finishing your software tasks on time and help out other engineers when requested. You have demonstrated that you have strong technical skills and you are a technical leader.

Now you have been asked to manage the next development effort as project manager. It makes sense to most people. There is a new project, someone needs to manage it. Why not appoint one of the best engineers to the role? It's an opportunity to grow and to enhance your skill set. It will be a career development opportunity. Makes sense right? Well, maybe… Project management does require a new set of skills that are not required as an engineer. Many of these are obvious. Scheduling, budgeting, and tracking the progress of work are all project management skills that can be taught and understood by a smart engineer pretty quickly. But the hard part of this new role is realizing YOU ARE NOT AN ENGINEER ANYMORE! ...well at least for this project anyway.

Here is why this can be tough. The number one talent that you have relied on in your career has been your technical abilities. Because of this, you will find yourself wanting to exercise these skills. During the project, technical challenges will pop up and your first reaction will be to jump in and solve it. DON'T! Let the engineers on the project solve them. It's their role now, not yours. Your job is to make sure they have all the resources and time to solve it. There is nothing worse as a software engineer than to have your manager telling you how to write your code. But that's exactly what can happen in these situations.

Utilize Empowerment
So how do you keep yourself from becoming a micromanager? The best technique I use is empowerment. There is no empowerment algorithm, an empowerment Java package, or an empowerment eclipse plug-in. You’ll have to step out of your technical mindset to understand and implement this one. Empowerment can be a tool for motivation and for delegation. On tough projects you need a team of people who are motivated to take on hard problems and to put in the effort needed to get the job done. You can’t solve all of these problems yourself. You don’t have time. So you will need other team members to work on them. Here are a few ways to empower your team:

1. Get them involved as soon as possible. Make sure the engineer estimates the durations for his or her own tasks. If they said a task will take three days, they will put in more effort to make sure they meet their own goals. If you set the task duration to three days, then their extra effort would be to meet your goals. And people like to achieve their goals, not yours.

2. Don't second guess their opinions. The engineer has been heads down in the problem. Trust their opinions. If you even slightly show mistrust in their opinion the problem and the solution becomes yours. Each time your opinion gets implemented, it becomes more your task and less of theirs.

3. Don't start tasks for them to finish. I once had a manager write the JavaDoc, define all methods, and parameters for me to help save time. He then expected me to fill in the code in each of his methods based on his documentation. I second guessed myself every time I had to change anything he did. I must have visited his office twice a day asking him why he chose to do things the way he did. The point I'm making here is when you start a task for someone, you become the expert and they will come to you to make decisions.

One of the main ideas in empowerment is the idea that people like to fill needs. When it is made obvious that no one else is the owner or expert in an aspect of the project, the person working those related tasks will take it upon him or herself to master those tasks. Your engineers will step up and fill the needed role. It becomes more gratifying to them knowing they mastered the challenges themselves and are not the expert.

Making the move from engineer to project manager can be exciting and a learning experience. If keeping out of technical issues is something you can't resist, then think of it this way. Upper management originally chose you for the job because of your technical leadership. Making sure your engineers are able to show their technical leadership will give upper management new candidates to manage the next project and you can go back to being an engineer.

Shook Labs Android App

2007-12-23T22:18:00.000-05:00

We just launched our new Shook Labs website. With the holiday shopping and all, we didn't have time to put too much into it. The site does give more insight into our Android App. Check it out at www.shooklabs.com.

New Android App - coming soon

2007-12-10T21:49:00.000-05:00

Michael Cook and I put up our two second teaser website for the Android App we are developing for Google's Android Developer Challenge. We Decided to give ourselves the name Shook Labs (Sheeley + Cook = Shook). We also came up with a slogan "When you at?" We're not sure if we’ll keep the slogan though.

We are starting to get excited about our idea. I wish I could say more about it but I've been sworn to secrecy.

Android Developer Challenge

2007-11-24T00:24:00.000-05:00

As many of you already know, Google has launched the Android Developer Challenge. The challenge will give away $10 million dollars in awards for "great" mobile apps built on Google's Android platform. Being the past founder of a mobile applications company, I could not resist. The ideas started flowing and after several brainstorming sessions with a colleague of mine, we came up with our "great" mobile app.

The colleague of mine is Michael Cook, past founder of CookWare, Inc. At this point, all we have are a few requirements documents, a slide show, and a basic Android "hello world, testapp" application. I never expect much when entering challenges like this, but who knows? Wish us luck!

Chasing a Constantly Changing API

2007-11-17T17:17:00.000-05:00

I was once waist deep into a development effort when a partnering development team informed us that they where changing their API again. The component we were developing depended on their components for data and capabilities. We had spent time interfacing with their component. We had been careful enough to isolate the interface to their API by creating a façade. This way, the two components were decoupled as much as possible and our component was somewhat isolated from future changes to the partners API.

Our partner was already changing their interface. Not a problem, right? The façade is the only subcomponent affected by this change. An engineer spends a few days reworking it and we move on. It’s that easy right? Well, no.

When this happens you need to make sure you find out why their interface is changing. Ask your partner why this change has been made and why this change was not thought of originally. If they do not have solid reasons for this, then be assured that their API will soon change again and you will find your team spending another couple of days updating the façade. I have seen this situation play out many times. Each time the partner swears that "this is the final change to the API" only to have it change again a week later.

Yes, the façade acts as a buffer to new changes but changing the façade still requires work. And no façade is completely perfect. Some changes might still bleed into other subcomponents causing many other needed changes. In fact, the more you need to update the façade, the greater the chance that the changes will effect all the subcomponents who utilize the façade.

In many situations you have no control over your partner's development practices. It is important to first identify when you may be dealing with an unstable API. Once you have identified the API as unstable, you have a few options other than using up all your resources chasing it.

Hold off on making the changes. Wait a few weeks before updating your façade to their latest API. You might also be able to wait till the end of the development effort to make the update. This way, you will skip a few interim API changes. I do have a word of caution on this. Make sure you’re not ignoring their changes; only skip the updates to your code. You want to make sure their changes do not drastically change or remove the needed data or functionalities you require from them. If you wait till the end of development, it might be too late to address the problem.

Send you partner your façade. Many partners will pushback on this. They might see this as more work for them, but it might actually save time for both of you. They have a better understanding of the new API and it will be a quicker change for them to make. They already know what changed in the API and why, thus cutting down on cross team meetings and emails.

Make sure you identify their unstable API as a risk to the project as early as possible. Assess your options; determine if your schedule, budget, or scope for the project is at risk. Chasing a changing API never seems like a big deal to the project until it is too late. If it is not identified and dealt with early then it will put the whole project at risk for failure.

Engineers and Marketing Myopia

2007-11-07T22:56:00.000-05:00

For those who are new to SheeleyTech, I am a software engineer at heart but more often I “act” as a project manager, product manager, and systems engineer. Because of this, I tend to find myself in a conflict of interest that, if I’m not careful, results in marketing myopia.

“Heads Down” Versus “Heads Up” Roles

The engineer’s role
Engineers love to learn and apply their newly acquired skills. They enjoy building products by using their knowledge, skills, and past experiences to design and create solutions. A large part of this enjoyment is the challenge of creating the product. Sometimes it is the ability to utilize a technology that the engineer has never used before. As a software engineer I can look back at the software products I enjoyed developing the most. There is the first time I used CORBA, or the first time I used RMI, or learning about and developing web services was a great experience. Keeping up with the latest technologies, gaining new skills, and creating products with new tools requires the engineer to focus on the development of the product. I refer to this as a “heads down” responsibility. The idea being that the engineer’s head is facing down at the computer screen writing code or reading about new technologies.

The product manager’s role
When you are in the role of product manager, systems engineer or even the project manager you need to be focused on the customers’ problems. What needs do your customers truly require? Your job is to make sure you are building a product that solves their problems. You need to be what I call “heads up” – researching competing products, learning about the customer, and gaining feedback from the customers. This process does not stop once the development effort of the project begins. Challenges and issues will come up during development. Decisions will be made halfway or ever later into the development of a product that will have a huge impact on the final product. These challenges will come from the development effort (technical issues) as well as from the customers (market issues). Both of these types of challenges need to be addressed with the interests of the customers first.

The Conflict of Interest

When the same person developing the product is the same person who is responsible for making sure the product will meet the customers’ needs, there is a natural conflict of interest. I speak from experience.

Once the development effort starts, the engineer begins to fall in love with his or her product. There has been long hours invested into their development. Thus the engineer has been “heads down” and the focus has been on the product. When technical issues come up, the first reaction is to find the best technical solution to the problem. This is how the engineer wants to solve the problem. Because the product manager and the engineer are the same person, the interest of the customer can get lost. For example, a drill bit engineer (if there is such a thing) will focus on the drill bit. The engineer begins to think that the drill bit is the focus and that the customer needs a really good drill bit. This is wrong. What the customer truly needs is a hole, not a drill bit. Issues need to be addressed by thinking about the need of a hole, not how to make the drill bit better.

If you share roles as an engineer and as a product manager, you need to spend equal time “heads up” as well as “heads down”. If you started your career as an engineer you need to fight your instincts to focus more on the product than the customer. Before dealing with any technical issue, take a step back and think only about the customers’ needs. Review any relative requirements created for the product. Revisit use cases and all the materials you created before you put your head down into the code. Seek out subject matter experts or even contact the customer to get their perspective on the problem. This way, in the end, you will have developed a product the customer needs rather than just a product you enjoyed developing.

Verizon FIOS in the Sky

2007-11-05T05:53:00.000-05:00

It’s a quiet Sunday afternoon. I’m reading an operations management textbook on the porch while my wife is off running errands. It’s a typical Sunday afternoon, until I see a plane carrying out a mission overhead. This mission is directed at a small box located approximately 7 feet from where I am sitting. As the plane circles around the route 128 area near my home, I can’t help but think about the battles being fought over my cable box. Only a few months ago I switched from Comcast to RCN. RCN had mailed me a flyer advertising their much lower priced cable TV service. I looked into it and could not see any reason not to switch. $20 a month cheaper, all the same channels, with the addition of DVR. So I switched. RCN won that battle. Now up in the sky is another company jumping into the fight, Verizon.

Verizon FIOS TV aerial advertisement over RT 128

At first I find this all a little odd. Here are large companies all fighting to be the provider of my cable television service. They are spending large sums of money, sending sales people door-to-door letting people know FIOS TV is available in the area, paying for aerial advertisements, setting up FIOS kiosks in the mall, visiting local businesses and giving out FIOS basketballs. I also get flyers in the mail almost daily from Verizon, Comcast, and RCN. Meanwhile, I am just looking out to see who is cheaper.

To me it seems they are all in a market where price is the main differentiator and just over the horizon most content will be available through the internet anyway. I know these companies realize this. So, it really makes me wonder why they are so eager to invest in, and enter into, the cable TV market. Shouldn’t they just be focusing on the internet market? It seems to be a no brainer that in 5 to 6 years from now all broadcasts will be through the internet. Customers will soon only require internet access.

Maybe these companies see cable television as a loss leader for future internet subscriptions. Currently television packages can be bundled with internet service. The fight to be my cable provider might actually be their chance to be my internet provider. When television is available through the internet and consumers realize they no longer need a separate TV service, these companies will not care. We will have become their internet service customers. If I’m right, look for your monthly cable bill to drop and the internet service to increase. This way when you drop your cable service most of your monthly payments will be tied up in your internet service anyway.

As a customer it’s hard to tell what the long-term strategy is for these companies. But enough of this, I need to go checkout the prices for Verizon FIOS TV.

Negotiated Schedules Affect Quality and Deadlines

2007-11-01T21:31:00.000-04:00

A while back I was at a meeting with a group of product managers from local software companies. The topic was the process of prioritizing requirements. When the estimated time of development came up, one product manager made the following comment:

“Estimates from engineers are always overestimated. They would want you to think all features would take about three years to develop. You need to negotiate the schedule.” …or something like that.

I could not believe what I was hearing. From my experience, engineers are usually over optimistic with their initial estimates. Only after thoroughly examining each essential step will an engineer increase their approximation to a more reasonable estimate. The fact of the mater is, software development efforts are notorious for delays and schedule overruns. This negotiation process is likely a common cause.

My guess is that this product manager probably feels a sense of accomplishment when the engineering team finally agrees to shorten their schedule. He probably then gets frustrated later when new releases are delayed. Product managers, project managers, program managers, and anyone else who has a say in persuading schedules must realize negotiating a development schedule does not mean the project will finish any earlier. The estimated delivery date is just that, an estimation. The actual delivery date will not be effected by the new estimations. It will not cause engineers to work any faster, it will not reduce the amount of work needed to be completed, and it definitely will not increase the number of hours in the day. The only thing a negotiated schedule will affect is a low quality product or a delayed delivery, and that is not something any manager should feel a sense of accomplishment about.

How Schedule "Should" Effect the Project Budget

2007-10-31T19:39:00.000-04:00

Talking with a lot of project managers I find that many of them understand the challenges of the triple constraint. Schedule, budget, and scope all need to be tracked and managed. But, many of them do not understand the direct link between schedule and budget. Many project managers feel that a schedule slip is okay as long as the customer agrees to the delay or if there is no missed opportunity.

“We met with the customer and they understand the situation and have agreed to
move the expected delivery date out one year.”

“Our competitors will not have these features in their product for
another two years. Even with a one year slip we will still be ahead of them by
six months.”

These points are valid points and the focus on the customer is very important when facing a potential schedule slip, but the financial implications for these delays need to be understood before moving forward with the new plan. Many times, delayed deliveries imply delayed revenue. Let’s say your customer has agreed to pay after the final delivery or sales are expected to start increasing after the new features have been added to the next release of the product. Even if the project has stayed within budget, the schedule slip might affect the success of the project in terms of the project’s net profits.

First, understand that a project is only undertaken when management feels the project will add value to the business (short-term or long-term). The completion of the project is expected to increase sales by 5% or the customer will pay $5 million for the final delivery. Schedule, costs, expected returns, and the required profits are all considered when calculating the success of the project. Changing the schedule will affect the required budget. A delayed schedule may require a smaller budget if for the project to still add value to the business. Take for example the following project.

A project is expected to last four years and is given a budget of $3.5 million over four years. The project will cost $120k in 2007, $1 millions in 2008 and in 2009, and $1.3 million in 2010. Added revenue is expected to be about $5 Million by the end of 2011.

Let’s say the cost of capital for the project is 15%. The expected Net Present Value (NPV) comes to $258,286. Great! A positive value means a positive growth for the business.

Now let’s say the project is expected to slip by one year. In most cases this would also impact the costs, but for this example we’ll assume the cost originally expected to occur in 2010 can be spread out over 2010 and 2011 ($700k in 2010 and $600k in 2011) thus keeping within the original $3.5 million budget.

This schedule slip changes the NPV to a loss of $63k! The project now reduces the value of the business!

What I want project managers to understand is that schedule is tied to the budget. Just because the customer is okay with your slip, you still need to make sure the project makes sense to the value of your business.

Kiva Mobile Fulfillment System

2007-10-27T18:22:00.000-04:00

A current xconnomy.com article introduced me to the startup, Kiva Systems of Woburn, MA USA. Kiva Systems has developed the innovative Kiva Mobile Fulfillment System (Kiva MFS). According to Kiva’s website, Kiva MFS “improves productivity, speed, accuracy, and flexibility” of their customer’s warehouse operations. How does Kiva MFS do this? With robots! Stubby orange robots drive along the warehouse floor. The robots carry the inventory pods around the warehouse storing, moving, and sorting inventory. Figure 1 is an image of the MFS system at work. The orange figures under the blue shelves (pods) are the robots as they are moving the pods around the warehouse. The system uses robots, bar code scanners, and an intelligent software system that communicates with each robot wirelessly.

Figure 1: Image of the Kiva MFS at work source: kivasystems.com (requires login)

Operation managers have the responsibility to lower cost, increase quality, increase the speed of operations as a whole and for each order, and at the same time ensure the customization of each customer’s order. In warehouse operations, speed is correlated with the employees’ knowledge of the warehouse. When items need to be stocked or when a new order requests a particular item, an employee must identify the location of the item in the warehouse and then physically travel to that location and back. Quality, on the other hand, is linked to the employees’ knowledge of each product as they must visually check the actual items being packaged for shipment against the ordered items. Error occurs when items are placed into the wrong order or when wrong items are misidentified. In many warehouse operations, each order is customized; tailored to the exact needs of the customer. To help relieve these requirements, orders can be batched. Orders are not fulfilled until a number of orders come in for the same set of items. Although batch ordering increases speed for the operation as a whole, it can reduce the speed of each individual order. An order can be placed at one o’clock but might not be fulfilled until Six o’clock when a larger order for those items comes in.

With the Kiva MFS, warehouse operations can increase quality, increase speed, and ensure customization of each order. The system allows warehouse workers to remain in one location while the required bins for each item automatically come to them while fulfilling the previous order. This reduces the time it takes each warehouse worker to recognize the location of the items in the warehouse and cuts the time that the worker would be required to travel to that location. Thus, it increases the speed of each order. In fact, Kiva Systems claims it can triple order fulfillment output per worker.

At the same time, the system increases quality by utilizing barcode scanning technology. The worker scans each item. The system then tells the operator which order the item must be placed in. This increases the quality of operations by ensuring the correct items are being placed in the correct order. Workers new to the warehouse no longer need extensive training of the location and identification of items in the warehouse.

The Kiva MFS also adapts the location of each product to optimize the warehouse. Slower moving items are moved to the back of the warehouse while faster moving items are placed closer to the workers. The system allows the warehouse to learn how to become more efficient over time, making the operations increase efficiency and adapt to new trends in customer orders.

The Kiva MFS is the beginning of the next generation enterprise solutions. Many current solutions are focusing on connecting departments with the needed information in a timely and useful manner. The current systems have improved the efficiency and decreased the cost of operations by optimizing the flow of information. The next generation of enterprise solutions will need to look toward robotic and intelligent systems that optimize the way we think and operate our businesses

Exploration Efforts Still Need Project Management

2007-10-24T21:12:00.000-04:00

A lot of projects start with a clear goal, an available budget, and the deadlines are already somewhat obvious. From my experience, companies are utilizing project management practices in these types of situations more and more. Companies are realizing that the execution of a clearly defined effort needs to balance the triple constraint of schedule, budget, and scope.

However, in my experience project management is not commonly utilized when the effort does not already have an obvious path and objective. An opportunity is understood to exist but the main tasks that need to be accomplished, the budget, and/or the schedule are unclear. In situations like this, companies tend to see the effort as an “exploration” and not a project. The “explorations” do not tend to follow any project management processes. This is a mistake. These efforts cost money, utilize resources, and tend to drag on without a final result. They end up adding no value to the company.

If you find yourself falling into this trap step back and think about why you are pursuing this ‘exploration” effort. In for-profit corporations, the end reason is for profit. You are pursuing this effort because there is some potential opportunity for your company to gain profits. Maybe you don’t have a clear understanding of the potential opportunity or how much it will cost. That is fine, but before starting the effort you need to at least come up with estimates. Determine what you are willing to spend for the estimation, decide what resources are qualified to complete the estimation, and give a deadline for the final estimation.

To complete your estimations, understand why you are investing in the effort. Get a good understanding of the opportunity and determine an estimate of the potential return. Estimate the window of opportunity you have or when the needed resource will be available to complete the effort. Deadlines will become more obvious and the project’s risks will become better understood (i.e. does the project that falls in line with your current business efforts). Next use your corporation’s financial structure to obtain the budget (if ‘x’ dollars are invested in this project over the life of the project and given the estimated return for this opportunity is ‘y’ dollars, our return will be a Net Present Value (NPV) of positive ‘z’ dollars).

The budget, schedule, and scope of all efforts need to be defined and project management is needed to manage the efforts. Understand and manage all efforts if you want them to be successful otherwise you are only wasting time and money.

Engineers know best - follow-up

2007-09-22T16:13:00.000-04:00

A while back I wrote the post, Engineers know best. As a follow up to that post, it turns out I made the right decision. The engineer who had promised the completion of his tasks on time put in long hours and did in fact complete all of his work on time. This was the case of an engineer who wanted to complete his tasks and who knew the challenge ahead of him better than anyone else.

Similar to this common lesson is to listen when the engineer feels the assigned tasks cannot be completed in time. As a software engineer I was always able to complete my tasks on time-but the tasks were not always done right. When pushed to complete an unrealistic schedule, corners will get cut. These corners might not show on the surface, but under the hood the code might be an unmaintainable mess.

A quick YouTube video, “How developers fix bugs”, is a satirical explanation of how software developers can cut corners.

The lesson to learn here is an experienced engineer needs to be trusted when it comes to planning schedules. As a project manager we know project management, budgeting, resource management, customer requirements, and we might even have many years of engineering experience. But the engineer knows his or her skills, abilities, and the hidden coding obstacles he or she will need to overcome. Listen to your engineers and trust their recommendations. The success of your project’s success depends on it.

Getting Customer Buy-in for Innovative Technology

2007-09-19T21:22:00.000-04:00

Many innovative technology creators experience trouble selling ideas for new software concepts or technologies to organizations that have solid operational processes. I find this especially true if the technology does not fit in with the organization’s current process even if the technology can help reduce costs, save time, and or increase quality.

To some, this seems like a chicken or egg thing. The organization’s current process does not match the use of the technology so they do not by into it, and the company will not change their current process because they do not have the tools needed to change their process. I see this as a misconception. Processes are created to gain efficiency and accuracy based on the resources, information, and time that constrains the organization. If a new technology comes along that changes these constraints, then the process needs to be flexible enough to become efficient and accurate given the flexibility in constraints that the new technology provides.

For example, consider the fictitious organization, Thinkmuch Inc. Thinkmuch is a logistics consulting company. Customers come to them for help on transporting large awkward items (such as houses and large boats) over long distances. Thinkmuch cannot afford to create detailed plans for transporting their customers’ items only to have the customer disagree with the methods and plans of transportation. So, Thinkmuch has come up with a process of two phases to create their plans. First they create high level plans and then get buy-in from the customer. They don’t waste time with many details on the first phase because if the customer doesn’t like the plan, the time creating the details of the plan is wasted. With Thinkmuch’s current resources, detailed planning takes weeks apposed to high level plans that only take hours to create.

Thinkmuch Inc. is now being presented with a technology called Processmuch. Processmuch allows Thinkmuch to enter in the dynamics and properties of the customer’s items as well as the items’ starting location and the desired ending location. Processmuch then takes into account Thinkmuch’s available resources, future weather conditions, the road and transportation systems that item might be transported in, etc. In fact, Processmuch processes all of the decisions that Thinkmuch does in both phases of planning. Using Processmuch the time to create the detailed plan (including the data entry and processing time) only takes one hour.

So does everyone at Thinkmuch see how Processmuch can help? Nope! Why? Because in the first phase, detailed planning is not currently done. The employees that do this phase see Processmuch as overkill and the employees who work on the second phase do not want to “waist time” entering in the dynamics and properties of the customer’s items. When the employees’ assessments of the technology find there way to the decision makers at Thinkmuch, the decision makers receive nothing but unfavorable reviews.

To prevent these situations, creators of innovative technology need to select their initial customers carefully and strategically. You need to select early adapters that understand the relationship their processes have with technology and the constraints that form them. Unfortunately, these early adapters do not usually have deep pockets and the non-early adapters (such as Thinkmuch), are usually the ones who have money to pay the higher prices. When selecting the early adapter you need to select ones that have visibility to the non-early adapters. The early adapter will prove the validity of your technology to the non-early adapter. The trick is finding the early adapter who has visibility to the premium paying customers.

Strategy in a SOA World – Three Strategic Principles

2007-08-09T22:32:00.000-04:00

So your company has a niche product. You specialize in one aspect of a larger system. Your competitors are virtually sitting right there next you in the same system. But they have their niche and you have yours. You and your competitor are placed into a large Service-Oriented Architecture and both of your services provide utility to the end-user through your modular and accessible interfaces. To gain a competitive advantage, companies must follow three strategic principals: Do what is best for the entire system, Focus on the end-user, and Offer help to your competitors.

1. Do what is best for the entire system. Think of the system as your business ecosystem. To completely understand this analogy of a business ecosystem read The Keystone Advantage: What the New Dynamics of Business Ecosystems Mean for Strategy, Innovation, and Sustainability (Harvard Business School Press, 2004). Your competitors are in many ways your allies. Their niche adds value to the whole system just as yours does. Together your system competes against other systems and solutions. Before acting on any strategic moves, make sure the move is in best interest for your entire ecosystem.

2. Focus on the end-user. Make sure you are focused on the needs of the end-user. Your service may not interact directly with the end-user or it might be a very small piece of the system, but that does not mean you do not need to focus on the larger direct needs of the final customer. The more you are focused on the needs of the end-user, the better you will be at adding features to your services that end up being used by the customer. Many companies focus on extending their niche in any way possible. New features add to the utility of your component but if the end-user of the system has no need for those features your efforts have been wasted. You only can gain share of the system if the system’s end-user needs your added features.

3. Offer help to your competitors. Your competitors in the system are looking to add features to their own services. Position your services to add value to their future efforts. If your competitors can add value to their product they will utilize it. If utilizing a feature of your product is accessible (it is a SOA, so it should be) and it is cost effective, it will be very tempting for them to utilize your new feature. If your offer is tasty enough they will go for it. As long as you are able to constantly add value for their use, they will use your service over attempting to create that service themselves. At this point, your competitors are now more dependent on your services. At the same time you are expanding your share of the system.

SOAs are great for end-users because of their ability to trade in and out loosely coupled components. If your components are required by the end-user and/or required by competitors’ products, which are then required by the end-user, your components will have a strong foothold in the system. The stronger your foothold, the stronger your position will be among the players in the ecosystem. This long-term strategy will add market share and expand your competitive advantage.

Testing Early and Often Can be a Wasted Effort

2007-08-06T22:20:00.000-04:00

We have all heard the saying, "test early, test often" but in many software development efforts this can be a very costly mistake. It is imperative for software project managers to understand the full added cost each type of testing will have on the final delivery date. In many cases, it is the timing of when to write these tests that matter the most.

There are three levels of testing, unit testing, integration testing, and system testing. Integration testing and system testing are not as flexible, so I will not discuss these two efforts in this post. Unit testing does have some flexibility.

Unit testing is a required means to assure that the smallest possible elements have been tested. Unit testing is a required process in testing a system, no question. But the timing of these tests and the level of detailed required need to be considered. Writing highly detailed unit tests early in a project adds cost to the current development phase but, more importantly, adds cost to future phases as well. Maintaining these tests can be extremely time-consuming. In iterative process models, units are rewritten and redesigned over and over again. Each change to unit requires changes to the corresponding unit test. The more detailed the unit test the more time and effort required to maintain and update.

Project management needs to be aware of the added costs and implications to the project’s schedule. The nature of the project, the type of development process, and the size of the system being developed all need to be considered in deciding the unit testing level of detail and what phase or iteration these levels should be enforced.

Unit Testing Levels of Detail
First let’s clearly define each levels of testing. They are numbered and described below from the least complex level to the most complex.

1. Algorithm Accuracy testing
- Testing the accuracy of an algorithm. In object oriented languages, this is
testing the return of a method based on a few basic inputs.

2. Full statement testing
- Making sure the unit tests execute every line of code

3. Full branch testing
- All decision points (i.e. if statements) are executed for all outcomes

4. Every loop tested at 0,1 and many
- Testing each loop (i.e while and for loops) when the loop is executed more
than once at a time (many), only once (1), and when the condition of the loop
keeps the loop from executing its block of code at all (0)

5. Boundary value tests
- Testing boundary values for boundary condition statements (i.e. if(size > 0
&& size <= 10) Boundary value tests would test this statement when size equals -1, 0, 10, and 11 )
6. Full predicate testing
- Similar to level 2, Full branch testing, adding the requirement for each
condition for each predicate must be tested. (i.e if(boolOne == 1 &&
boolTwo == 2) Full predicate testing would tests all combinations when boolOne
equals 1 and does not equal 1 and boolTwo equals 2 and does not equal 2)

7. Path testing
- This level of testing implies all the previous levels but each branch, loop,
boundary, and predicate test must be done independently of the others.

Each level of detail adds more benefit to the reliability, accuracy, and even the complexity of the system. There is no question about this. Determining what level of detail is required by the stakeholders needs to be done regardless of the development process chosen, but understanding the cost of each level is important in estimating cost and schedule.

Software Development Processes
We’ll now describe the basic types of development processes. Depending on the project’s process, the costs of testing differ greatly.

Waterfall process – a sequential effort of phases (requirements analysis, design, implementation, testing (validation), integration, and maintenance). Each phase occurs only once. Traditionally, testing occurs once the implementation phase finishes but many times unit testing occurs during implementation. Either way, these efforts only occur once.

Iterative process – a non-sequential effort where phases can be revisited after there initial completion. A common iterative process, Agile process, comprises of short iterations. Each iteration visits or revisits each software phase. Think of an iteration as a small waterfall. Iterative processes reduce the level of risk to a project by giving the stakeholders of the project small releases of the product at the end of each iteration. The stakeholders are able to evaluate these releases and add feedback, suggest changes, and foster new ideas for the product. Stakeholders can better evaluate whether to continue on with the project or not. If continued, the project can redesign, and recode the product using the stakeholders’ feedback. This method ensures that the project and the stakeholders are communicating towards build a better product throughout the effort. This is contrary to the waterfall processes that only allow stakeholders to evaluate working examples of the final product at the very end of the effort.

If you are using the waterfall development process, once the implementation phase is done, you will not revisit this phase. Therefore, determining the cost attributed to each level of detail is simple. If an iterative process in being used, each level of detail will increase by a multiple of the iterations in the process. In many iterative development efforts, the code written in the first and even the second iterations will greatly change once the stakeholders give new feedback and make new requests. Writing highly detailed unit tests for these iterations will most likely be a wasted effort. Proceeding iterations will also have the added burden of editing and changing these tests.

Making sure these tests are written efficiently can cut down on the complexity and the level of effort needed to maintain these tests. Tools such as the Spring Framework can help to cut down drastically on the complexity of the setup code needed for each unit test and should always be used on medium and large efforts.

Levels of details such as levels 4, 5 and 6 should be post postponed until the system and software requirements have been mainly worked out. These levels add a large amount of extra code to the test suite. Not until the stakeholders seem to settle on the majority of requirements and details of the system should these levels of detail be added to the test suite. Although these tests greatly increase the quality of the software, their cost to write and maintain surpass their benefits to the early iterations.

Level 7, path testing, is a level of detail that adds great quality to a system, but it is extremely expensive. A testable section of code’s complexity can great affect the cost to create and maintain tests at this level. Some argue that requiring engineers to write full path tests influence engineers to keep the complexity at a minimum. I agree with this point, but in the early iterations of a development effort code complexity is irrelevant. These iterations are done to prove a concept to the stakeholders and to iron out the integration effort problems and system level issues. The last iterations before a system is released should be saved for this level of detail. The added costs in adding these tests to the system will be outweighed by the time and effort required to maintain these tests.

Conclusion
Every software project is unique and it is up to the management to understand the costs involved in each decision they make. Test adds quality but also adds cost. Test wisely adds quality but can reduce cost. As a project manager, make sure you understand the complexity your decisions add to future phases and iterations of the project. More detailed testing can be postponed until later interactions where there is less future maintenance needed to update the tests.

Trends in Venture Capital Funding in the 1990s

2007-08-01T22:03:00.000-04:00

Growing companies need to know the trends in the venture capital market to help them understand the conditions that lead to better chances of receiving financial capital. It is imperative for a business that is seeking venture capital funding to understanding where the venture capital market is heading in order to best position the business to receive funds. To do this, it is important to understand the historical trends in the market and to understand the current position of the market in order to know where the market might be heading.

As an entrepreneur, the report issued by the United States Small Business Administration Office of Advocacy in August of 1997 titled, “Trends in Venture Capital Funding in the 1990s” by Nicole Onorato, is of great interest. The data and the conclusions about the venture capital market in the 1990s will help to identify current and future trends of this market.

When first reading this report, it seems that in the early 1990’s the amount of venture capital money was increasing as the market matured and the number of VC firms decreased. A quote from the report states, “While the capital under management has increased, the number of firms managing it has decreased.” This statement infers that there is a negative correlation between the number of firms and the amount of money under venture capital management. Thus, as a potential seeker of venture capital, a market with less venture capital firms means there is a higher probability that there is more money under venture capital management, and therefore, a greater chance to gain funding.

Also stated in the report, “The fastest growing funding source in the 1990s has been corporations, which contributed 19 percent of funds in 1996 — a $920 million increase from 1990, when they contributed just 7 percent.” This statement could be a very powerful to and business leader looking for funding. As a seeker of funding, this could mean that corporations may be the cause for the increase in VC funding during the first half of the 1990s. It also can be inferred from this statement that corporations are contributing more and more to the birth of small businesses in the United States. What is economically good for corporations must be good for small businesses. A politician, who understands the need of an economy to create small innovative businesses, might think that corporations are increasingly contributing to venture capital funds. A politician may pass more legislation that favors large corporations in order to increase venture capital funding.

When first reading this report, these conclusions are agreeable. As we investigate further, using better sampling and statistical techniques than the author uses, these conclusions may not be so clear. In fact in one case, we will show that they are just plan wrong.

Questioning of the Sampling Techniques Used

Looking closer to the sampling techniques used in the section titled, “Trends In Venture Capital Funds”, one should begin to question Nicole Onorato’s conclusions.

First, Onorato uses two conflicting sources of data for her first point in this section. “In 1985, the professional venture capital community had $19.6 billion under management.
By 1995, the total had grown to $43.5 billion, a 122 percent increase.” The source of this data is from Coopers and Lybrand[1]. In the same paragraph, she states that the amount in 1995 was $37.15 Billion. This amount is from a different source, Horsley[2]. Did Onorato choose Coopers and Lybrand to inflate her point that the venture capital community had a significant increase in capital?

With the title of the report being, “Trends in Venture Capital Funding in the 1990s” it is also interesting that the author includes the 1980’s in her initial calculations. It would be helpful if Onorato gave a reason for why she went back to 1985 to demonstrate a trend in the 1990s.

“The fastest growing funding source in the 1990s has been corporations, which contributed 19 percent of funds in 1996 — a $920 million increase from 1990, when they contributed just 7 percent.” This is another conclusion that Onorato makes in this section. Why was 1996 now added to the date range? Before, in the same section, 1995 was the last date in the range. If the report’s purpose is to report the trends of the venture capital market then the sampling methods used should be explained and kept consistent for all samples.

Questioning of the Statistical Techniques Used

The report only uses percents of samples taken from each year to show the trends in the venture capital market. Additional information that would be useful to a consumer reading this report would be the presentation of charts and the use of other statistical tools aside from the percent increase between two arbitrarily chosen years.

For instance, a chart showing the money in venture capital management for the years between 1990 and 1995 could give the reader a visual understanding of the data given. Figure A (page 7) of this report is the chart that should have been given. There will be a further analysis of this chart.

Another chart that would be useful is a scatter plot between the number of firms and the amount of capital under venture capital management. Onorato infers a negative correlation between the number of firms and the amount of capital. A scatter plot would help make her point. The scatter plot that should have been given is in Figure B (page 8). There will be a further analysis of this chart as well.

A report discussing trends should include charts with trend lines. Instead of leaving it up to the reader to spot the trends that are concluded in this report, a trend line would be useful. A coefficient of correlation between the number of firms and the amount of capital under venture capital management would also help in justifying Onorato findings. As we analyze the data that should have been provided, Onorato’s finding should become clearer and justified, or will it?

Changes in Thinking

Newly constructed statistics based on the same data given in the report present a different set of conclusions than that given in the report. Figure A, Figure B, and the coefficient of correlation between the number of firms and the amount of capital under venture capital management have been calculated and presented. There is also a closer examination of the data presented in the chart from the report given in Figure C.

Figure A gives a graphical representation of the amount of capital in venture capital management. The chart also shows a trend line to help give a better description of the trend. Looking at Figure A, is this a significant increase in funding in the early 1990s? The trend line has a slope of 0.65. That’s only a 9.7% increase from 1990 to 1995. Given that inflation from 1990 to 1995 increased 18.6 percent[3], the amount of money in the 1990s at the time of the report has actually decreased. There is a strong difference in the 122 percent increase stated in the first sentence of the, “Trends In Venture Capital Funds” section of the report and the findings given in Figure A.

Figure A.

Figure B shows an even more drastic change in conclusions given in the report. As Figure B shows, the trend line of the number of firms and the amount of money under venture capital management is a positive slope. This shows a slight positive relationship between the two. Also, when the coefficient of correlation is calculated, the result is 0.226. This contradicts the author’s implication that the number of firms in the US are decreasing while the amount of capital is increasing. Our calculations show that there is a positive correlation between the number of firms and the amount of capital available for businesses needing funding. Thus, there is a greater probability that there will be a greater amount of capital under venture capital management when there are more venture capital firms.

Figure B

An analysis of Figure C shows even more inconsistencies in Onorato’s interpretations of the data. “The fastest growing funding source in the 1990s has been corporations, which contributed 19 percent of funds in 1996 — a $920 million increase from 1990, when they contributed just 7 percent.” But a look at the chart, in Figure C, shows an interesting bit of information.

Figure C

First, it should be noted that that the actual values of this crowded chart are not given and that the yellow bars displaying the amount each year that corporations commit to venture capital seem to blend into the background of this chart. A closer look at these bars actually shows that between 1990 and 1995 there is not a large growth trend in corporate contributions at all. In fact, 1990, 1991, and 1992 shows a decline in the amount committed by corporations. There is an increase in 1993 and 1994 but then in 1995 there is a sharp decline again. The actual trend line of this chart cannot even be calculated because the values for each bar are not given and the increments on the Y axis are by the $500 millions even though most of the bars do not even reach $500 million.

Onorato mentions an increase in the amount corporations were contributing. To make this point Onorato, for unknown reasons, added 1996 to the range of data. In 1996, corporations’ contributions increased to over one billion dollars. But this doesn’t show a trend. The year 1996 is an outlier, an unusual year. Adding this year to the chart gives a false impression to the data. Maybe this is why Onorato added 1996 to her calculations. Then, to conclude that corporations are the “fastest growing” based on a one year spurt is a great misunderstanding of the data.

Conclusion
After further analysis of the data presented in the report, conclusions from the report need to be reexamined. Consistent samples of the data, graphical charts, trend lines, and calculated coefficient of correlation should have been given in the initial report. When looking for trends in data as complex as the trends in financial markets, such as the venture capital market, detailed statistics should be used. Other useful calculations such as the variance in these trends, and the probability of events in the future, would have also been useful in a report such as this. With a report issued by the United States Small Business Administration Office of Advocacy, one would expect there would be more scrutiny in the numbers and conclusions issued to the public.

[1] Coopers and Lybrand, Seventh Annual Economic Impact of Venture Capital Study.
[2] Horsley, Trends in Private Equity; National Venture Capital Association, annual reports, 1992–1995.

[3]U.S Department of Labor Bureau of Labor Statistics http://www.bls.gov/cpi/

The Evolution of Apple

2007-07-30T07:16:00.000-04:00

A great Harvard case about Apple Inc is available on http://hbswk.hbs.edu/item/5729.html for $6.95

The Apple case originally appeared in 1992 and has been rewritten 5 times since. "The company always looks a little different, yet many of the core issues that pose challenges for it remain constant," says Yoffie
From the executive summary

Executive Summary:
Apple's continuing development from computer maker to consumer electronics pioneer is rich material in a number of Harvard Business School classrooms. Professor David Yoffie discusses his latest case study of Apple, the 5th update in 14 years, which challenges students to think strategically about Apple's successes and failures in the past, and opportunities and challenges in the future. Key concepts include:

Apple has an undeniable hit with the iPod, yet faces the question of whether the growth of that business and Apple overall can be sustained.
Looking at Apple through the lens of the company's previous chief executives gives students insights into why Apple lost its way after Steve Jobs left the company.
Student opinion of Apple tends to be excessively positive or excessively negative, depending on the company's current fortunes.

I suggest taking a look at it

A New Strategy for the Enterprise Software Industry (Post 2 of 4)

2007-07-23T22:25:00.000-04:00

A SheeleyTech working paper

This is post two of a four post series.
1 A background of the enterprise software industry.

2. An examination of this industry using the analysis techniques in Clayton Christensen’s book Seeing What’s Next. I analyze the customers of this industry by categorizing them into undershot customers, overshot customers, and non-customers. This analysis determines which market segment offers the largest opportunity. I then look to see if the industry is signaling a change to target this market segment.

3. A competitive comparison determining which players are best to implement the strategy based on their resources, processes, and values.

4. My strategic road map for the company that is best fit to become the next leader in the enterprise software industry.

Customer Analysis
Undershot Customers are most likely very large corporations who will pay exorbitant amounts of money for slight improvements to their current enterprise systems. These customers can take advantage of economies of scale. The sizes of these businesses allow them to profit off of any improvement to the enterprise system.

Overshot Customers are small to medium size businesses that cannot adsorb big costs for every upgrade to the enterprise system. These companies tend not to pay for new improvements or the latest release. These companies have to anticipate big returns for any purchase or upgrade to the enterprise software.

Non-customers are small companies that tend to find cheaper alternatives that might not be the best solution but help get the job done. In these businesses you will find collections of excel applications that have been transformed into advanced accounting and management programs.

According to the US census bureau, in 2004, 99.7% of companies in the United States are small to medium size businesses[i]. If my overshot analysis is correct, then most businesses in the US are overshot customers. Anyone who works in an IT department that manages SAP or Peoplesoft enterprise systems, or knows someone who does, is aware that these systems are highly complex and upgrades are very costly. Integrating new features into these systems require IT departments to work weekends, cause downtime to the systems, and require an upfront purchase of a license and hardware for the new components.

According to Christensen’s model, if there are overshot customers in the industry then low-end disruptive innovations, displacing innovations, and downward migration of required skills will be occurring.

Looking at the software industry, there should be signals that these trends are emerging. We will look at the OnDemand business model as a low-end disruptive innovation, niche CRM and customer contact solutions as displacing innovations, and the emergence of Web Services and webapps as a downward migration of required skills.

The OnDemand Business Model is one that allows customers to use the software under a variety of payment plans. Companies with the business model offer solutions that do not require upfront costs for new hardware or software installations. The software is priced at different levels that allow their customers to pick the plan based on the level of usage required. These solutions give small and midsized businesses cheaper solutions than purchasing more expensive licenses and new hardware.

Niche CRM and Customer Contact Solutions are just a few displacing innovations that have emerged. Displacing innovations take aim at a specific feature of an existing product line. Solutions that target customer relationship management and customer contact campaigns are just a few of the areas where new players are sharpening their expertise. Their customers do not want to pay for an entire enterprise system or have already purchased one but are willing to pay for specialized features particularly needed for their industry.

Web Services and Webapps are examples of downward migration of required skills.
Web services are a means to define and expose application interfaces. Web services allow for easy upgrades and integrations of existing system. Web services are interfaces that define and verify integrated systems. Also, Web services allow enterprise systems to be loosely coupled, so that each component of the system is less dependent on the other components. This reduces the experience needed by IT departments to maintain and integrate new components into the systems and reduces the downtime required for most integration efforts. This also allows niche solutions to be created without complete knowledge of the other enterprise systems in their customers’ existing systems.

Webapps are applications that are accessed over the internet. These applications require now hardware, downloads, or installations. They are practically a webpage that looks and feels like an application. New enterprise solutions are emerging that are exclusively webapps. These solutions do not require an IT department or even a highly technical employee to do the setup.

These signals and trends are clear signs that the enterprise software industry is changing and is refocusing on the overshot customers who make up most of the business market. Next, I will analyze the competitive battles and determine which players are preparing to emerge as the next enterprise software leader.

[i] Small business is usually defined as under 100 employees and medium size businesses are usually defined as companies with 100 to 500 employees

A New Strategy for the Enterprise Software Industry (Post 1 of 4)

2007-07-22T22:11:00.000-04:00

A SheeleyTech working paper

This is post one of a four post series.
1 A background of the enterprise software industry.

2. An examination of this industry using the analysis techniques in Clayton Christensen’s book Seeing What’s Next. I analyze the customers of this industry by categorizing them into undershot customers, overshot customers, and non-customers. This analysis determines which market segment offers the largest opportunity. I then look to see if the industry is signaling a change to target this market segment.

3. A competitive comparison determining which players are best to implement the strategy based on their resources, processes, and values.

4. My strategic road map for the company that is best fit to become the next leader in the enterprise software industry.

Background
In the 1970s, IBM and other software companies created the first widely used enterprise software applications. This disruptive technology allowed companies to digitally manage the business’ payroll and financial accounting. These systems were host-based. Host-based architectures perform all functions of the system on one machine. The storage of data (financials, and employee information), the processing of the data, and the presentation to the user are run on one mainframe.

Since this time, a series of sustaining innovations has occurred. Functions that address, human resource departments, customer relationship management, supply chain management, inventory management were added to enterprise software systems in order to meet the demands of the current market. The enterprise systems also changed into client-server architectures to increase the accessibility of the systems and to take advantage of processor power of multiple machines. These systems are a collection of dedicated database machines and dedicated processing machines. Users access these systems through client applications on their local PCs, many times through a web browser. These systems became widely popular and large enterprise companies such as SAP and Oracle capitalized on their demand.

In the past few years, new types of enterprise systems are emerging. Buzzwords such as OnDemand, Saas (Software as a Service), SOA (Service-Oriented Architectures), and webapp (web application) are used to describe these new types of systems. Companies like Salesforce.com, SoundBite Communications, WebEx, and RightNow Technologies Inc. are the new players in this field. These systems do not require the customer to host software on their networks. There is no IT department required to maintain the systems and many of these applications use an onDemand billing model. These models bill the customer each time the system is used or allow for multiple pricing plans rather than purchasing a license or other expensive one-time charges.

A TRUE benefit of using web services document style messaging over remote procedure call (RPC) style

2007-07-19T23:13:00.000-04:00

Before reading this post, if you are not familiar with web services check out
http://www.ibm.com/developerworks/webservices/library/ws-docstyle.html
or
http://www.java-tips.org/java-ee-tips/enterprise-java-beans/document-handling-in-web-services-applica.html
or even
http://en.wikipedia.org/wiki/Web_service

The top three benefits of document over RPC are validation, asynchronous processing, and a less rigid contract between the client and the server. The first two benefits are more of a coding convenience than an added benefit and don’t really impress me. To me the third benefit is really the power of document style. But until my current project, I have yet to have a situation where I was able to utilize this powerful benefit. I want to explain my case for why a less rigid contract is the only powerful benefit and then I want to share with you a situation where documents style messaging is really the only option. (Note: there is this idea of using document style to save state, but my disagreement with this idea will soon become a completely separate post on SheeleyTech. For right now, just trust me. For most systems, don’t try to save state through web services.)

Validation in XML This benefit uses the power of XML. Document style uses the power of XML to validate the message where as with RPC the code behind the operation does the validating. So either the code does the validating of the XML. No big deal. (except that it allows you to have a less rigid contract, but that’s more than just validation)

Asynchronous Processing Ok another feature of document style, but I can name many other ways to get my RPC style call to be asynchronous for the client. Again, no big deal.

A Less Rigid Contract Now this benefit is cool. The idea here is when a client uses an RPC style web service; the client application relies on that specific method signature. Any change by the client of the parameters will break the client application. In other words, the interface cannot ever change unless it changes on the client as well. With documents style, this isn’t the case. Changes to the server interface that in RPC would change the interface, in document style only change the schema and therefore will not break the calling application.

So if you are like me, the last benefit sounds really cool, but where would you need it. I mean, I have used documents style in the past, but only to help future efforts that might need to make changes to the interface. …well, actually I used it only for the sake of using a documents style, RPC would have done the trick just as well. Besides, I’m really not quite sure how I could later change the schema without hurting any client applications. If they are relying on some data being in the Document message and I remove that data from the schema, won’t this cause them to have errors? This whole idea of using document for “great” benefits over RPC has really escaped me. ...until now.

My current project is enhancing a really cool application for the Air Force Research Lab. The need is for the system to be able to act as a standalone application (i.e. the client and the server are all on the same machine acting as a single application) and also act as a service and a client. (i.e. the client will be located on one machine and the server be on another machine handling service requests from whom ever is calling it).

The reason document style is needed for this design is because of the services that the server is exposing to the client. There is a ton of them (for this post we have N of them). Each service has its own set of parameters. In order to handle direct and web service mode, at first we thought we needed N times 2 handlers for each service (one to handle calls to the service directly and one to handle the call through web services). (See Diagram 1 below) Instead, if we use document style messaging for the web services, we can define the parameters for each service in the schema. We can have 1 handler for all calls thought web services and one handler for all calls to the services directly (See Diagram 2 below).

Diagram 1 A quickly made diagram of the system using RPC style messages

Diagram 2 A quickly made diagram of the system using document style messages

Before, the reason we needed N web service handlers was different parameters for each service. With document style, the parameters are defined in the schemas that define the structure of the XML document. The service proxies are needed to gather the required data for each service. Once the proxies have gathered the data, they can pass on the single parameter to the web service handler. The web service handler now only needs to make a single generic call that passes in the single parameter.

This design is simpler and contains fewer dependencies. It should also cut down on the time needed to build the system. I hope this now gives you a concrete real world use of web service document style messaging.

Radio can still do what google and itunes can't

2007-07-18T21:22:00.000-04:00

Last night I listened to the both the director and general manger of sales for WFNX Radio in Boston (http://fnxradio.com/1/home.asp). They were talking to my ebusiness strategy class at Bentley College. They talked about the radio industry and challenges they face in this new internet world we live in. I found it interesting to hear that they didn’t see the iPod or online advertising (Google, Yahoo!, etc.) as a threat to their business. They are sales guys so my first reaction was, oh yeah right. But the more I think of the points they made, the more I think the terrestrial radio industry does have a chance of survival.

Their argument was that people listen to terrestrial radio because of the connection to community, and the local customization that they offer. The example they gave was the following. When you only listened to downloaded music, you lose touch with what is going on in the local news, music, and sports scene. You become disconnected with the constant real-time stream of up-to-date information. They noted that people put radio station bumper stickers on their cars of because people identify with local radio stations. You don’t often see people with a New York Time or Google bumper sticker.

I think they might have a point but I feel the radio industry is going to have to move much faster and adapt new technologies that will keep them ahead or equal with their competitors. If community and local customization are their key advantages, then they need to capitalize on these points.

Right now when I listen to a radio program I picture a group of DJs or talk hosts sitting in a room with microphone talking. I think they need to step out of their stations and into more locations. They need to integrate more with the local community and host their shows in traffic during rush hour, or at the local mall. They do this now, but they need make it less of a special event and make it an every day thing. Google can’t pull up in traffic next to its audience or visit the local Dunkin Donuts, but local radio can.

Take the local Fox news station here in Boston http://www.myfoxboston.com/myfox/pages/InsideFox/GoodDay?pageId=5.2
Their morning program does these promotions called Zip Trips. Every Friday they do their morning show from a new town. They promote the town all week and give new facts about it. When that Friday morning comes along, people from all over the town are at the broadcast crowding the backgrounds of the cameras.

Listeners want to feel connected, and they want to feel that they belong to something. If terrestrial radio can capitalize on the personal local community aspect of their business, then they do have a chance. Online advertisers are constantly looking for ways of focusing ads to specific customers. But if radio can keep their devoted communities of followers, then advertisers will continue to tap into these valuable markets.

Web2.0 and Mortar

2007-07-17T22:17:00.000-04:00

We all know the story of the dot-com boom and bubble. Ecommerce sites were popping up with hopes of becoming successful businesses. The hype grew so big that people were predicting the end of malls and regular retail stores. Now that the hype has come and gone and regular retail still remains. Now most businesses have an online and a store presence or also known as “click and mortar”. Turns out, having both a store and an eCommerce site is the best strategy in retail.

Now we have web2.0 (http://en.wikipedia.org/wiki/Web2.0). I guess web1.0 was the checkout feature and now web2.0 is the wiki, social networking, customization, blogs, and more. Websites are now appearing that are web2.0 businesses. Myspace, wikipedia, igoogle and other sites are set to be the next thing. These technologies are not necessarily profitable but companies are paying big money to buy them up for fear of missing the web2.0 boat (the purchases of friendster and youtube come to mind). But what if the conclusion of web1.0 turns out to be the proper conclusion of web2.0? What if the profitable outcome of these web2.0 business models is not just to create a website but to incorporate the features of web2.0 into a physical store. We can call it “web2.0 and mortar” or “wiki and mortar”.

Could web2.0 move to the real world? Could the experience I have when I walk into Wal-Mart be different for me that for you? Could the isle next to the milk be coffee for me but cereal for my wife? Probably not. But I can see large communities of people change the how a store operates or what it sells? a wikistore? Stores are constantly doing market research to find out what their customers want. Why not just let them define it for the store. Customers logon to the stores website and edit the wiki-inventory and add and remove new items.

Or what if you can network with other customers in the store? Would the social networks that myspace creates be created for a brick and mortar store? If a community forms around your store are they more likely to buy? Will they feel like it is their store? (i.e. a more loyal customer base.) Just like communities and social groups helped make Ebay what it is today, could the same happen for the local grocery store or for the local pizza shop? Are we as consumers on the verge of having more control or say in what we buy and what services are offered to us? Will web2.0 become a profitable business model for Brick stores? I think the answer to this will be if the large collective knowledge of customers make companies more profitable than the a few very smart executives. I think we are not far away from finding out.

Engineers know best

2007-07-16T22:15:00.000-04:00

In my current position, I switch from a project management role to a software engineering role depending on the project. Each project I get a different perspective of what is needed to make a project a success. This volley of perspectives, in my opinion, is making me a better manager than if I was no longer an engineer.

For example, a few months back I was acting as a software engineer. My job was to develop a utility component for a large planning system. The component was an HTN planner (http://en.wikipedia.org/wiki/Hierarchical_task_network) cool stuff! Anyways, with two months left before the project was due, I still had a lot of code left to write. The project lead at the time kept pushing me to delegate some of the work to another engineer as to assure that the development would finish on time. The problem was that all of the tasks that were left depended on the piece I was still working on. I couldn’t have someone else work on them because the code wasn’t ready yet. I was unable to explain this to the project lead and he assigned someone to those tasks anyways. The engineer now working on those tasks quickly realized he could not properly work on his assignment and decided to do the best he could. In the end, it actually took longer redoing his tasks. A few weekends and nights at the end of the project helped finish everything on time anyways.

Now I am acting on another project as the project lead. Last week we got word that the project’s due date has cut short by two weeks. It is up to me to figure out how to remove two weeks from the schedule and still complete all of the tasks. The two options for cutting back on a schedule are cutting the scope of the project or increasing the man power. Unfortunately, we cannot cut back on the scope. Given the nature of this effort, all pieces are absolutely required. The only thing left was to add more people. Using the cash reserve planned into the project, I am able to assign another engineer to the project.

I ended up asking one of the engineers to look over his tasks and look for something to carve out for someone else to work on. The reply, “sorry, there is no room on my tasks for someone else.” I looked as the description of the tasks he had again. It was the largest set of tasks on the project and it was on the critical path. It had to be broken up. I brought it up to another manager who had worked closely with this engineer a lot. He said he would talk to the engineer. Again the engineer would not change his mind.

Then it struck me. Here I am, doubting an engineer on his recommendations for the tasks that he knows more about than anyone else. He is a great engineer. Who am I to doubt him? He says he can get the work done quicker if needed but only if he is the only one working on that part of the code.

I have decided to trust the engineer and not assign anyone else to the project. I hope he is right.

UPDATE: See Engineers know best - follow up