If you’re taking Strategic Management (Strama), you’ll most likely be required to present an EFE Matrix for your chosen business.
An EFE (External Factor Evaluation) matrix is a strategic tool you can use to analyze and evaluate your business’s strategies in relation to the market and external environment. It is a component of the SWOT analysis and is often paired with an IFE (Internal Factor Evaluation).
An EFE helps you analyze how your business is responding to the changing world around it.
When evaluating the surrounding world, you look at it through various perspectives: economic, social, technological, governmental, political, legal, and competitive. Just as you would when deciding whether to buy a house or not. Is it nice? Is the location good? Is the price ok? Is the neighborhood peaceful? Etc etc.
One of the cases our class got to work on was about a hotel called Mandarin Oriental. The hotel was based in Makati but was recently closed because its long-term lease with Ayala Land already expired. The goal was to create an EFE Matrix for Mandarin. As input, we were given a few points about Mandarin. We were also given the profile of its target market, and a few economic high-level data about the Philippines.
Once we got all the available information assessed, we proceeded with creating an EFE Matrix. Below I’ve posted our team’s matrix.
A typical EFE Matrix looks like the table shown above. You may color it up a bit, make it sexier, but overall it should be similar. Your matrix should include the specific opportunities and threats that are relevant to your industry, weight, your rating, and weighted score.
Below are the steps in creating an EFE Matrix.
We gave Mandarin Hotel a weighted score of 2.15, way below average. This means their current strategies were not working well enough. We think there were opportunities they didn’t fully maximize. For instance, their revenue growth was only 6% compared to the overall industry growth of 15%.
The numbers you put on your matrix can be subjective. You can write anything but they should be accompanied by good, intuitive judgment. When you do your Strama presentation, panelists will ask you to explain your EFE Matrix. Make sure to be able to defend your matrix with facts. Most importantly, remember to go through the process consciously and meticulously. Creating your Strama paper begins with this first basic step.
I haven't defended yet. Most of what I know about the actual defense process I got from the grapevine. And of course, from my Professors.
Just yesterday someone showed me an app on iTunes. "If we develop something like this, how much will it cost?" he asked. "Can you give me a ballpark figure?"
He's not the only client that asks questions like this. In fact most all of my clients ask me for ballpark figures without them giving detailed project specs. My best approach is simply to educate the client on the cost factors. This, assuming the client is not from the industry and doesn't have an idea. (If the client has an idea and still bullies me into giving him a ballpark, then am gonna kick him in the ass and send him to outer space. =) Just kidding.).
In this post I'll outline some of the factors I consider when estimating app development projects.
Purpose of the application - what is the applicaton for?
Audience - who are the intended users of the app? The design of an app will be dependent on the audience type. If it’s a kids app, for example, the mechanics and the design should cater to the needs of kids.
Platform & operating systems - which platforms & operating systems would you like to support? The more platforms and OSes you support, the bigger the development cost since we’ll have to spend extra time with testing and optimization.
Features/mechanics - which features would you like to include? Features which include a highly tuned user experience, integration with third party APIs, complex databases, massive backend infrastructure, would make the app more expensive.
Our participation - what is the extent of our participation? Do you need us to cover certain aspects only, or should we cover everything including maintenance as well?
When needed - if you need us to rush the project, we might need to add more resources in parallel early on.—Oftentimes this would mean an addition to the budget.
Once we have the requirements in, we’ll review them with our technical personnel, and then sit down and make estimates.
There are times when we make disclaimers and advise the client the budget may change after project discovery. Often, only when we’re done with discovery are we able to fully drill down the specifications to the level where we can confidently estimate development costs. This happens a lot on large projects. We'd indicate this in the contract and rework the budget after full discovery. If the client agrees, then we proceed.
Overall budgeting is a tricky business. Developers want to have more projects and would desire that an agreement with the client be closed the soonest. On the other hand, if they rush too much, they could get into trouble. I've fallen into this trap many times. Took me a while to learn.
I'm passionate about business, art, and technology. For more about me, click here.
Not sure if you'll find this one helpful, but here's a book I co-wrote with a bunch of industry colleagues. You can click the image if you wanna check it out.
Ateneo Graduate School of Business
University of San Carlos