iSite

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”.

 

 

 

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

 “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.

 
 Figure 1 - Set the outgoing email settings.
 

Step 2

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

 

 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

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.

 

 

 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.

 

 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

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…

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

 

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:

• http://code.msdn.microsoft.com/KB971831/Release/ProjectReleases.aspx?ReleaseId=3235
• http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=21953
• http://code.msdn.microsoft.com/Project/Download/FileDownload.aspx?ProjectName=KB971831&DownloadId=7285

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

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

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

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 merits¹. 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.

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.

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 »

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.

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