preload
Jan 24

A recent article in the Harvard Business Review by Roger Martin, lent us some fascinating insights into the rapidly changing world of capitalism.

His main idea is that the harder a CEO is pushed to increase shareholder value, the more the CEO will be tempted to make moves that hurt shareholder value.

These words jumped off the page!

The author was fundamentally challenging the longstanding corporate aim of maximising shareholder value. He argued that it was impossible to continually increase the return to shareholders.

“Most executives figure out that Shareholder value creation and destruction are cyclical. They can push it up in short bursts, but in due course share prices will fall again”.

He also was able to show the numbers behind his argument, taking several typical large corporations and highlighting these trends over the longer term.

Incidentally, one of the central aims of the iSite strategy is to maximise shareholder value(!!), mainly by measuring CFROI (Cash flow return on investment).  We take the view that business propositions have a much shorter lifespan these days so the average life of an ‘asset’ is 3 years.

In researching this a little more, we find that long held views on this are changing. Jack Welch, the former General Electric chief who is credited with coining the phrase in 1981, said last year that the emphasis he placed on shareholder value was misplaced.

“On the face of it, shareholder value is the dumbest idea in the world,”
“Shareholder value is a result, not a strategy…your main constituencies are your employees, your customers and your products.”

Alan Greenspan has also recanted:

 “I made a mistake in presuming that the self-interests of organisations, specifically banks and others, were such as that they were best capable of protecting their own shareholders and their equity in the firms”.

alangreenspan

 

 


 

So what is the alternative?

According to Roger Martin in his article:

“Companies should seek to maximise customer satisfaction while ensuring shareholders earn an acceptable risk-adjusted return on their equity”.

With this strategy the CEO can focus on building the real business.

Customers become the top priority; with the focus on improving products, services and operations. This replaces a relentless drive to increease profits above all else.

Underpinning this idea is the mathematical certainty that there can only be one goal. Linear programming is a technique for optimising a given variable subject to other constraints.

Taking the example - Roger explains that you cannot maximise both the value of outputs in a factory and the quality of products shipped. You have to pick one main objective function and treat the others as constraints. 

So the recommended approach is to make Customer Value your main goal, subject to creating a minimum shareholder value.

As CEO of iSite, this has really touched a nerve.  I have always believed that the “customer is king” and that by building a loyal customer base, a company would be successful in the long term. As we look at the larger multinationals, you have to question if some of the actions they take on a daily basis are on behalf of shareholders?

We will discuss these ideas in future posts, and I will share some insights as we adopt this strategy at iSite.

- Dave

Jan 11

 “I would like to use SharePoint to send alerts and notifications”.

We have received this request numerous times from our customer support teams.

So to help you out, let’s take a step by step approach to configuring our SharePoint server to support alerts and notifications.

As a starting point, the server name is teowebdev001 and we have all SharePoint services installed on that one server. We also have the SMTP service installed.

Step 1

The first action it to setup Outgoing E-Mail Settings. For the  as Outbound SMTP server, we will use the local server, teowebdev001, and the email address. It is recommended to use a dedicated email address for notification, preferably one accessible by the SharePoint administrator.

 sp-article2-img1
 Figure 1 - Set the outgoing email settings.
 

Step 2

Next we check if SMTP service is running, Open IIS and click on SMTP…

 sp-article2-img2

 Figure 2 - Open IIS, click on SMTP

 

Step 3

We will use these logs to check if the updates were successful. We enable logging by Right Clicking on SMTP and choosing Properties, the general tab will be highlighted and select the tick box Enable Logging

sp-article2-img3

Figure 3 - SMTP Properties 

 

 

Step 4

Now we need to configure SPF (Sender Policy Framework) with the ‘pass’ option for the SharePoint external URL or IP (depending on your SPF configuration options).
SPF is required to indicate that SharePoint emails are not forged. SPF is located on the email server.

Note - If the SharePoint outgoing email is from the same domain as the users emails there will be ‘Received-SPF: pass’ information in an email details.

 

 

sp-article2-img4

 Figure 4 - Configure SPF 


Step 5
 

We can then check the user email settings on SharePoint -  we need to make sure that the user has an email address configured.

 

sp-article2-img51

 Figure 5 - User email settings


Complete!

Now you should be able to receive alerts and other SharePoint notifications. If there are problems or investigation is required SMTP logs, which are located here C:WINDOWSsystem32LogFilesSMTPSVC1, are great source of information.

Note - If you don’t receive emails even though you have all the settings right, and you have tested them, then we would recommend to add a user email address also to the SIP Address field.

Good Luck!

Tomasz

Tagged with:
Nov 26

The following brief article documents a workaround to an issue installing SharePoint 2010.
SharePoint 2010 installation error cause by .Net Framework 3.5 SP1 issue (KB971831)

SharePoint Foundation 2010 (Windows SharePoint Services 2010 Beta) is available now for download from both MSDN and from Microsoft public website:

http://www.microsoft.com/downloads/details.aspx?FamilyID=906c9f5a-6505-4eba-bf24-95e423ac1703&displaylang=en

Once you have successfully run the SharePoint Product and Technologies Preparation Tool it present a screen which looks like this…

sp-article1-img1

You will get into the following error when trying to run SharePoint setup file…

 sp-article1-img2

When you search for KB971831 you will find that Microsoft does not expose the required file and you are asked to contact Microsoft Support

http://support.microsoft.com/kb/971831

So to fix this issue, use any of the following links to quickly get hold of the file and be able to finalise your installation:

Feel free to contact me if you have any queries tomasz.romanowski@isite-solutions.com

Tagged with:
Nov 12

The Enteprise Ireland CEO forum was held today in Dublin Castle.  There was an impressive delegate list - around 270 CEO and CFO’s from the public and private sector gathered to listen and debate key topics of current interest. Oliva ‘O Leary from RTE was the panel chair, and Mary Coughlan TD was the keynote speaker. Ahem.

I spoke with two people in my network and saw some familiar faces but otherwise there were lots of men with grey hair in suits, which must be a sign of being successful! Where are all the young entrepreneurs?… it was whispered they were probably too busy keeping the plates spinning back in the office!

And so onto the memorable speakers…

Mike Fitzgerald from Altobridge reinforced the idea for us of “finding the gap between the giants footprints”. They essentially kick started with an idea that the larger players were just not interested in. This is a notion that I read about some time ago called Blue Ocean Strategy - interestingly Mike has also spun out a company called Blue Ocean wireless…

He touched on the recession creating new business models that would never have made it before - he gave the example of a large multinational vendor building a GSM network in an emerging market and taking a lot of risk… for a share in the future revenue.

Peter Gray from ICON described the history of the company and their growth is nothing short of stellar! From an Irish SME with 5 people in 1990 and 500k turnover to a 600 person, NASDAQ quoted global player in 2008. Remarkable. It was great that he mentioned how they got lucky several times, being in the right place at the right time. They certainly rode the Big Pharma wave in the 1990’s. He also gave a fascinating insight into the challenges facing the industry right now… (we also talk a bit about these challenges on our site here).

When asked about the approach to innovation, his catch phrase was that ICON is not an early adopter but a fast follower. They make decisions, and move hard and move quickly - and this applies to back office internal functions as much as external customer facing propositions and sales activities.
Some of the key themes that came up:

1. Can we become a low cost economy again?

The general consensus was not on your life. I felt many people missed the point as it’s never just about cost. Ireland should be aiming to become an ‘Excellent Value’ economy - giving consistently excellent service for a fair price - and that applies across the board … Tourism, Software, Food, Agri, Pharma, Life sciences …even manufacturing (well maybe not).

2. When will things pick up?

Interestingly a lot of CEO’s surveyed said they were all right themselves, but the Irish economy as a whole was in trouble for 2010.  Again the consensus was that it will be 2011 before we start to see things improving at home.  Going slightly against the grain, iSite are looking forward to 2010 with some optimism, and a strong pipeline in certain areas of our  business. There are challenges within each of our business units, but looking to next year, for us it is a glass half empty or half full scenario… and we have firmly made our choice.


Second best Quote of the day

Peter Gray CEO ICON Plc    “Listen, follow it hard, go after it quickly”

 

The final wrap up was succint and powerful. Fair play to Pat Cullen (Managing Partner with Deloitte) for nailing his colours to the mast. I scribbled a few notes to capture what he said

Best Quote of the day

Pat Cullen, Deloitte     “The private sector has done it’s bit and now we need the government and the public service to play it’s part”.

Over the past few weeks leading up to the budget it seems that the silent majority may not be pushing their case. For the coming months into 2010 it will be vital that they do.

So a thumbs up to Deloitte and EI for a well organised and insightful function. Philip from ITA and I enjoyed the single course lunch that followed (washed down with tap water … how times have changed…piffle)…

the presentations from the event are available here

Tagged with:
Nov 06

I’m continuing with my look at the agile manifesto and how following its principles is what really drives a team to become Agile.

..we have come to value:

Working Software over comprehensive documentation

If you’re in the business of software development then I have to assume that want you want to do is deliver working software that does what your customer wants. That might seem obvious but the fact remains that far too often software projects get mired in activities that get in the way of that goal. The worst culprit is usually a process-driven requirement to produce comprehensive low-level design documentation, something that frequently involves endless cycles of reviews, updates and more reviews until the documentation is signed off. In some cases this process can last months without any actual software being produced. The sad fact is that you have to produce documentation because… well, because the process says that you have to produce documentation!

It might be argued that doing this helps uncover design issues that haven’t been thought about but this isn’t necessarily true. The likelihood is that no matter what, you’re going to end up changing some aspect of your approach because what looks good on paper mightn’t actually work in the real world. The paradox then is that the more detailed your design documentation, and the more effort you’ve put in to produce it, the more likely it’ll turn out to be wrong and go out of date once development actually starts. You’re then faced with a choice: defer revising the documentation to the end of the project or keep updating it as you go. If you don’t update it you have to ask the question as to why you did it in the first place. If you do update it then you’re giving yourself more work to do, work that distracts from the need to produce something that actually works. Your project will start to look suspiciously like a tech writing project with (if you’re lucky) some coding thrown in.

An agile approach recognises that it’s okay to not be 100% clear on our low-level design before we start coding. If anything we can often have a better understanding of the problems we face if we start by writing some code. Having said that, we certainly don’t want to start development without a clear idea of what approach we’re taking. The high-level architecture, the strategic approach if you will, should be thought out and can be captured in a formal way if necessary. The tactical view, exactly how we’re going to implement parts of the project, can wait. Being Agile is about deferring decisions until the last minute possible and recognising that we are better off having software that the customer can actually play with. The “classic” agile iterative approach helps here. We produce small amounts of functionality in short iterations and regularly deliver it to the customer. As we add more functionality we might change the existing implementation, maybe subtly maybe not but the customer will start to see their requirements being met. This is another other critical benefit of writing code early – we can start delivering early and reassure the customer that they will get what they want (often the reason why they insist on comprehensive documentation!).

Of course, documentation can be a really important output of any project. Most of the projects we work on here at iSite are done for external customers who take ownership of the code once the project is complete. We also tend to use contractors a lot which means that a project with multiple phases could have a different team on each phase. Producing comprehensive documentation as part of the final deliverable can make a lot of sense in these cases. It helps with knowledge transfer and capturing the small details that might otherwise be lost as teams change. What we should always consider doing though is deferring the production of this documentation to the end when it’s less likely to change. Automating its production can ease the burden of producing the documentation. We can produce UML diagrams from the code (and not the other way around). Capturing team knowledge with a Wiki during development and then formalising that in a knowledge base at the end of the project is another way to ease the burden while providing useful documentation at the end of a project.

The bottom line is that an agile team is constantly focused on the end result – producing working software that the customer wants.

- Fintan

Tagged with:
Oct 23

We were talking about the Agile Manifesto and what makes a team Agile…

…we have come to value:

Individuals and Interactions over processes and tools

A lot of companies I’ve come across seem to think that having lots of processes is the way you make software projects successful. It seems to be that the bigger a company is (or aspires to be) the more process they think they should have. Anyone who has ever had to work under that kind of regime knows that you frequently end up having to subvert the process in order to get things done. Processes get in the way of productivity and the team ends up trying to find ways to get around them so they can achieve their goals. The process becomes redundant, existing for its own sake - little more than a box-ticking exercise providing false security.

Sometimes tools are put in place to help make processes easier to work with but the end result can often be the opposite. I worked on a project last year where all code changes were tracked as work items in Microsoft TFS. Policy stated that you couldn’t check any code into source control unless it was associated with a work item. All well and good and something that has its merits1. However the work I was doing didn’t fit into any of the neat boxes that they had created their work items to reflect. The result was that it took me a couple of weeks to get a new work item and workflow defined, created and uploaded simply so that I could check source code in.

An Agile team recognises that people are smart and will always try to find better ways of working with each other to get things done as efficiently as possible. It’s no co-incidence that processes are usually created by people who don’t have to use them so Agile teams are typically self-organising. We decide and put in place the processes that work best for us to help us do what we need to – deliver working software. This must be a learning process. Reviews after each iteration and after the project has finished are important so that we can learn what worked, what didn’t and how to improve how we do things. These lessons can then be applied to subsequent projects.

Tools can help but sometimes the best tools are the simplest. Hand-written index cards, coloured post-it notes and a wall-space to stick them can often be much better than a software-based work item tracking solution. Apart from the serendipitous discoveries than can be made by someone walking past the wall there’s a lot to be said for the “arts and crafts” approach of hand-drawing a graph showing how much progress you’re making and sticking it up on the wall. The key thing is to allow the team find what works best for them and empower them to do it.

How people work with each other, how they interact, is just as important. Regular contact is better than structured meetings where not everyone may have an interest. We’ve all been there – someone calls a meeting with the entire team and within five minutes most people realise it’s a waste of their time. An hour-long weekly status meeting can be replaced by shorter, regular meetings every morning – the daily morning stand-up of Scrum and XP. You get early visibility of issues and the team has less disruption and a clear idea of the day’s goals.

Structure and processes are important otherwise a team can descend into chaos with little control. These need to be as lightweight as possible giving the team just enough structure so that there’s enough control and visibility to help the team achieve its goals. The best people to define this structure, and the tools that they might use to help them, is the team itself. People will find a way to get things done so get out of the way and let them do it.

- Fintan


[1] – Incidentally, this is a policy we’re following on a different project I’m working on with iSite at the moment. The difference is that although we have clearly defined work items like ‘User Story’ and ‘Bug’ we also have a ‘General Task’ which allows us to capture those edge-cases that get thrown at you from time to time. If we find that we’re doing lots of ‘General Task’ items that are the same we can always create a new well defined type if we think it’s necessary.

Tagged with:
Oct 18

Is it 12 months already? On Thursday night, the fast fifty awards rolled around for 2009. We were pleasantly surprised with 3rd place in 2008, and there were rumours abounding that this year, we might go one better. Clontarf castle was a fine setting, and adding the horseradish to some well roasted beef, we had been listening to people talk about the future, growth, innovation and positive thinking!

Some highlights of the night…

Paul Rellis from Microsoft touched on some of the recurring themes including cloud computing and innovation. When he spoke about self worth, he described how Irish people are at a low ebb in terms of our sense of self worth just now… (it seems even an Irish Tenor can’t open his mouth with offending people in New York … just yesterday!)

The other speaker was Michael from Pigsback, who did some unashamed promoting, which is understandable I suppose! He also briefly described Dublin as a potential business village, and called on everyone present to support each other, to work together to lead the charge. It struck a chord to some degree, and I resolved to up my networking in the coming months.

Thankfully, after chatting to some of the award winners on the night, there was lots of stuff to be upbeat about and some fighting talk about ‘next year’.

In the end, we came a highly commendable fourth, which didn’t deserve a place on the podium, but still something to be proud of!

A big thank you to all our staff, customers and business partners for helping to make this happen.

Tagged with:
Oct 06

In mid-February 2001 a group of 17 software developers got together at a ski lodge in Utah. Each was a recognised thought-leader in the lightweight methodologies that had been emerging over the previous few years and all were convinced that there was a need for a rethink about how software projects are run. It was at this meeting that the term Agile was first applied as a collective term to all of these lightweight approaches but the most important thing that came out of this meeting was the Agile Manifesto. This short statement, “a rallying cry” according to Martin Fowler, set out in clear terms what being agile is all about. (For a good background on the meeting and how the manifesto was produced have a look at the pieces by Martin Fowler, Dave Thomas or Robert Martin).

So what does the Agile Manifesto say? Well to save you clicking on the link here it is in its entirety.

 

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Pretty simple and to the point, isn’t it? Now read the manifesto again carefully because most people focus on the main points and can miss a couple of things it says that might not be so obvious.

The first thing is that in the opening sentence the manifesto states that “We are uncovering better ways of developing software by doing it and helping others do it”, introducing some important points about any truly agile approach.

“We are uncovering better ways of developing software by doing it…”

An agile approach is one that continually evolves and improves based on experience. A truly agile team constantly inspects itself to see how it does things and see if there’s a way of doing it better. This cycle of act-inspect-improve is an important concept in any agile approach and is typified by the iteration and project retrospectives of XP and Scrum.

“…and helping others do it”

An agile approach is a collaborative approach. A project team can’t work in opposition to itself or else the project will fail. This actually has a wider implication because if you assume that the goal of a software project is to produce software (and if you’d been on some of the projects I’ve been on in the past you might doubt that assumption) then all stakeholders are part of the same team. All too often a team can be fractured between functional areas such as development, test and product management, each with their own competing goals. An agile team has a culture of collaboration where there is a single team with a single agreed common goal.

I’ll talk about the main points of the manifesto in later posts and skip straight to the closing statement because it’s just as important. It contains a point that is frequently missed by those who don’t understand agile software development and even by some agile proponents I’ve worked with in the past.

“That is, while there is value in the items on the right, we value the items on the left more.”

In other words, while agile approaches typically emphasise the importance of some things over others (such as working software over documentation) it doesn’t do this to the total exclusion of those things it places less value in.

Opponents of agile approaches who don’t really understand them will frequently say things like “agile teams don’t write documentation” or “there’s no process”. That’s not strictly true.As agile developers what we say is that our goal is always to produce working software. While documentation may be useful the main effort has to be on producing working software not just documents that describe it. Teams also can’t work effectively without some kind of framework. Agile methodologies like eXtreme Programming or Scrum have processes that need to be followed but they are lightweight.  They exist to help the team get things done not to provide them with more things to do.

Equally some agile developers miss the point. They too say things like “we don’t write documents” or “we don’t need to follow a rigid process”. That’s also not strictly true.Documentation may be a useful project artifact, for example to help with knowledge transfer in cases where different teams handle different phases of the same project. We should be smart about how we produce documentation though. We can defer its production until as late as possible or automate its production to reduce the amount of effort required to keep it up to date. An agile team should also have processes in place so that there is visibility and control of the project but we should keep these processes as light as possible so that they support the team rather than distracting it from the task at hand.

As you can see, the opening and closing statements say some important things about an agile approach.  In the next few posts I’ll get into the meat of it by taking a detailed look at the core points made by the manifesto and show how following them is what helps make a team agile.

- Fintan

Tagged with:
Oct 01

Back in the day it used to be that if you suggested taking an agile approach to a software project the first thing out of people’s mouths was the question “what does that mean”. Unfortunately now that agile practices have gone mainstream people respond with their own often incorrect assumptions or understanding about what it means to be “agile”.

Over the last year as I’ve worked to introduce agile practices to iSite I’ve become increasingly aware the dangers of failing to grasp what other people’s understanding of “agile” is. For example I had someone say to me a few months ago they knew all about agile software development or as he termed them, “black-box projects”. A “black-box project” doesn’t sound particularly agile to me. Where’s the interaction, the collaboration and the learning about what worked and didn’t? Others seem to think that if you have a continuous integration server then all of a sudden you’re “agile”.

Of course we agile practitioners are also guilty of something similar as we often focus too narrowly on our own favourite practices. We can often fall into the trap of becoming so tightly wed to methodologies that we end up with a rigid process that gets in the way of project goals thereby defeating the purpose of agile software development in the first place. We too need to constantly remind ourselves about what it means to be agile.

So, what is “agile”? What does it mean to be “agile”? Luckily for us we have a ready-made answer to both of these questions.

Continue reading »

Tagged with:
Jul 11

I spent a magical evenings fishing this past week. We went looking for mackerel off the north coast of Donegal. With the swell and spray of the sea in my face, I caught five fish. Arrived back feeling relaxed and happy, a highly successful outing.

mackerel
What does this have to do with iSite you might ask!

It struck me that what we are trying to do - build a successful business in 2009 - might be a lot like the mackerel fishing. 

Right now I am working with John O Gorman of the ASG Group to transform iSite into a sales led organisation. We have set ourselves some aggressive targets, and to achieve them will be a significant challenge.

 

 

Sales, like the fishing, takes careful planning and lots of preparation. What fish are we hoping to catch? Where are the fish? Is the tide coming in or going out? Are we using the right tackle?

So many variables and questions to answer. In re-organising our sales function, we have gone through the same process of qualifying what, where, who and how.

Once all of these basics are in place, it is becoming easy and enjoyable to do the simple things well at the right time and see the results pay off. So last wednesday evening I was not looking to land a 1000lb tuna (although they have been caught here!!), I was content to catch a few mackerel for the barbecue the next day. With that confidence gained, we are planning to take a boat out next week and go after more mackerel and some pollack.

Who knows … this time next year we might begin to dream about landing one of those giant blue fin.

- Dave

Tagged with: