Nokia sells more handsets than any other manufacturer in the world

Nokia sells more handsets than any other manufacturer in the world. Who has not ever had a Nokia? Look at your chargers drawer and you will find one or two Nokia chargers. They have been very successful so far but there is a “but” here, they do not seem to be the industry visionary, they look more like the big fish who will follow other's innovation trend and mirror their successful products. I am sure some bells are ringing in Nokia's strategy steering committees, they do need Marketing driver, something that makes customers to feel identified to the brand, something that makes a difference and keep customers loyal to their products.

Maybe, a key differentiator is one can buy and use all Apple's products (iPod, iPhone, Mac, …) but there is no way you will do same with all Nokia products, unless you are manager of a mobile's shop ;-) When Nokia launches a new product there is not big expectation unlike Apple's product launch big shows chaired by the great Steve Jobs.

Nokia products are, most of the time, excellent quality and worth the price but customers don't come the shop with the purpose of buying a Nokia but the one they favourite, happens to be a Nokia handset. That makes Nokia their own worst competitor, the quality / price ratio is the measure of the their success and if they launch a handset with that ratio lower than average, it will become an immediate failure.

Apple is the fashionable company

Apple is the fashionable company, the trendy, the one to imitate and follow when we talk about design and usability. They launched the iPod, the iPhone, the iPad and are probably designing the iWho-knows-what-else.

Their business model is shocking and very very successful, based on a few principles: a) scarcity marketing, b) high quality hardware and wide offer of software applications through the App Store and c) high edge prices. They sell a expensive product but customers perceive it is worth the price. Reason for that is not easy to explain but very real though.

We all know where Apple comes from, they were defeated by Microsoft in the PC software market and, as a side effect, in the hardware market too on the 80's. In those days, using an Apple product, namely, a Macintosh computer, was only for a minority and rare (strange?) group. They even had specific group names (Maqueros in Spain) and they became the “indie” version of the personal computer's users, they did differently for years because they did believe their product was the best. That conviction makes a difference on marketing.

When an Appler pays for an Apple's device, they purchase something more than the product itself, they buy the right to be part of a group of people who deserve the best devices on earth, who will enjoy the best customer experience ever imagined, who will consume the most creative applications and trendiest content offered by the App Store and who do not mind to pay a higher price for that.

Is it all against all ?

It just came to my mind when some time ago (wow, almost two years already passed) I launched a blog to gather posts on how mobile, internet and software industries were nearing each other and creating a wider market where the competition was more open and less constrained to their respective vertical markets.

After the two years have passed – so quick and nice – I would like to come back to the topic and see who is competing to whom and in what markets.

Let me limit the scope of this and upcoming posts on the big players: Nokia, Google, Yahoo, Vodafone, Microsoft, Amazon, Apple and Dell – although maybe Samsung could be a better one to follow.

... more posts to come on this topic ... stay tuned ...

hahaha

.... price was 4, he cheated and said 5, I gave 7 and asked him to take only 6 but he took 7 so I left 75% tip at the end. ...

Vertical, horizontal or mixed organization ?

There is a number of ways to organize a team and, from my point of view, there is none better or worse than the others, it simply depends on the goals, focus and priorities of the team.

What I call a vertical organization consists of a project focussed structure where the team is built up when the project starts and disbanded when the project is closed. There is as many teams as projects and first - and often exclusive - priority is delivering the project on time, cost, scope and quality.
This structure team is especially effective for critical projects and short term efforts but do not necessarily delivers long term and high quality products.

On the other hand, we can organize a team in a horizontal fashion, with specialized resources for specifics domains and not transient teams but stable in the mid term. In this way, deliverables quality increases as same people are doing very similar work for some time so they become experts in their technical and functional domain.
Horizontal organization is the most usual for operations departments and those where the stability weights more than the agility.

Is anyone better than the other? Yes, the balanced one is the best. Depending on the maturity of the company, department, systems, and professionals, depending on the business priorities, timeframe for meeting objectives and which one of the triple constraint (quality, cost and time) weights more, there is balance on vertical and horizontal functions.

There is always room for horizontal functions such as Technical Office, Quality Assurance, Program Office, Operations, Business as Usual projects, Architecture among many others, as well as some others must be driven as vertical functions, such us, first implementation of a new architecture or system, complex projects with many dependencies and so on.

Finding the balance is, as always, the challenge...

Entry or exit milestones ?

As I described in a previous post, a milestone project schedule is often requested by senior management as a way of a "helicopter view" of the project schedule, focussing the attention just in a few dates that can be tracked and reviewed easily and quickly.

Milestone is defined as a zero length event that is relevant for the project, that can be "project initiated", "product A delivered", "risk matrix distributed to stakeholders" amongst others.

A milestone can be related to the beginning (entry) or to the end (exit) of a project phase, task or activity and which one to report is part of the project management methodoly used and can change from project to project or it might well be driven by the resourcing strategy.

The end of phase, activity or task is relevant when a major deliverable is linked to it, for instance, the end of the analysis and design phase should become a milestone if a key design document will be delivered at that time. It also can be the case that one of the phases of the project is outsourced and they can invoice as soon as the products are accepted by the project manager. In such case, it makes sense to report the "analysis and design phase completed" as a milestone.

On the other hand, when, as part of the project, a number of hand overs need to happen, it is important to highlight the handing over date to allow the taking over team to plan accordingly. For instance, when a software is released and the test activity starts, that is a zero length event that will happen in a particular date and has to be tracked and published to the stakeholders as part of the project plan.

Milestone based project schedule

Project scheduling can be approached in a number of different ways depending on the granularity and detail required.

The most detailed approach consists of going down to the activity level, let us say, what as less as one person can develop in as much as a week. This schedule can not be reported as such to management and a higher level view must be prepared. It will describe project schedule in terms of phases, stating start and end dates for each relevant phase of the project. This way, we will have a good picture with regards by when resources will be needed and by when the deliverables linked to every phase will be completed.

For senior management, sometimes, it is again, too detailed as they want to track events like when the project will be completed or when the resources can be released to be utilized for other projects.

This brings us to the milestone based schedule, where only a few – up to five – dates are reported. Some examples could be: products delivered, project closed, project initiated, products ready for test and so on.