Simple OneNote blog test

The quick brown fox jumps over the lazy dog.

Making your distributed offering sensible

When working in a distributed manner, the one thing to bear in mind is the applicability and/or sensibility of what you are trying to offer online in a distributed context. The best model will mean you will need to spend some time with your client. There is an ancient tangible nature to business and I feel there always will be... it is a good thing. The relationship between supplier and customer is important and it needs to be physically re-inforced at some point in the engagement.

Getting back to the sensibility of your value to the market - the medium needs to be appropriate and sensible. Don't deliver ice to eskimo's type thing. Similarly - the latest offender in this regard: www.pleasehelpme.com - an online PC helpline; which is great, but only when you PC is not broken. Delivery of an online solution will require you to be online. And if your PC is broken and you cannot get online... how can you seek help?

So what does the BBC Olympic coverage have to do with this?

Having the flat to myself this weekend - I took the opportunity to "veg" on the couch and channel hop - I came across the BBC Olympic coverage presented pretty much 24/7 on several channels showing all the sports in which Britons had qualified to compete in Beijing representing their nation.

This still seems to be going no-where, but wait... The presenters were talking about the time of day according to the time of day IN ENGLAND - not in Beijing - as if in some alternate reality. So the point of this entry to is to talk about the need to localise delivery - ensure that your message is tailored to the audience and their environment. This is particularly important to make the intended recipient of the information to feel comfortable. Or maybe the BBC presenters feel at home too.

Indian companies have been known to work during your working day rather than their own - so right now at 12:11pm in New York, USA... half way through the work day, it is actually 21:41 (they have a half zone there) in Mumbai, India. Talk about night shift. Global commerce in a 24/7 business... in fact so firms now offer a 24 hours working day at centres in the States, India and China effectively getting through two man days "while you were sleeping" (to quote Tom Friedman in "The World Is Flat").

The ultimate goal is to reduce the difference (distance, time, language) between people. So next time you see Sue Barker saying good morning to you when the brunch team take over at 11am on BBC1; say good evening - because it's 6pm there!

Gap analysis

Tricky thing this gap analysis. It is quite an obvious process by definition - analyse the gap between two things. Simple right? Surely? Um... no.

Having recently been asked to conduct such an exercise, I found myself flummoxed at the simplicity of the statement of work - yet the sheer complexity of the task itself. Even in itself - there is a gap between the theory and the practice.

Simple life's lessons phrases abound - let me try and use some of them to illustrate the point.

"Establish a level playing field" (no-one likes to run uphill, even in the second half)
You see, it's all about metrics and creating a relativity to the gap - making it quantifiable. I could ask you to do a gap analysis between life in London and Spain. Like things you will look at are cost of living, standard of living (measured by pollution, green space, education, etc), exchange rates, job opportunities, etc. You have a common ("level") set of metrics ("playing field") to work with.

"Compare apples wth apples" (cos apples are good for you)
I won't ask you to do a gap analysis on sea levels and the coffee temperature. Unless you are Dr Seuss in which case it may be amusing, but uninformative as the gap is not measureable. But even apples don't have to be compared with apples - this is a stupid phrase; you cannot compare the life in London with life in London. That's nonsense. Stupid phrase.

"Do not wearing rose-tinted glass" (cos only Elton John looks good in them)
Besides the fact that this is a general rule anyway, how can you look objectively at a gap? Are requirements not met if there is a workaround - it depends on your point of view really. The metrics again must be commonly accepted and agreed - like using fahrenheit or celsius to measure heat. But when it comes down to feet and inches; some people's feet are bigger than others! The human element tends to creep in - and so do hidden agendas (but that's big dark glasses not rose-tinted spectacles).

In short - I have been working in between writing this - so it's likely that it is unstructured... glib in parts, deep in others. Or just drivel all round. It should provide some insight, Insallah.

Distributed Teams and Delivery Apathy

Organisational behaviour topic could be the impact of lack of 'face time' with the client and the delivery focus from the distributed teams. Not being located in the same place as the client and having someone else managing the relationship with the client could lead to less focus/concern being placed on quality deliverables (in content, timeliness or otherwise) by the distributed team as they may not have to face the music should delivery not meet expectations.

Strong ownership by the distributed team, clear and concise expectations management and a sense of diligence with regards to meeting the needs of the client should be pervasive in the organisational culture.

Also, penalty clauses in contracts may help ;)

Application Support and Service Desks

In a distributed environment, this topic is a tricky one. The efficiency gains of using a cost-friendly resource base in a distributed location during the development stage needs to be assessed against the long term impact on the ability to service/support the application post-implementation.

Without having an agreed partnership with a distributed vendor, there is no obligation to support the application once development is complete. In fact, even if you are partnering with a vendor, there is no obligation to support the application unless the support is agreed up front or is there as an option in the contract between oneself and the vendor.

If the goal is a solid application and good post-implementation support, then the application support and service desk deliverable is a key for all companies that engage with suppliers that use distributed vendors for solution delivery. Customers will need to ensure that they are getting the whole "product" from their supplier - which is not stage-focussed but geared around the actual lifespan of the application in an organisation.

This is, therefore, a critical success factor for the long term customer-supplier relationship and the success of the project post-implementation.

What has been your largest project management issue from your most successful project?

I would suggest that the most complex issue to manage in projects that I have managed, being part of as well as being the client is expectations management. It is something that a project manager must be cognisant of, but is an issie borne of delivery.

I feel that wihout effective delivery tools and methodologies, clear and concise communication is not possible with regards to the expectations of the project stakeholders. Ambiguity exists in so many places in projects. Project managers need to ensure that the client (and the delivery resources) understand the project and the detail that they are agreeing to at the various project sign-off stages.

Only a project manager who understands the project deliverables and has the trust of the client and the delivery team can hope to be able to manage their expectations.

The first way to resolve this issue is to really work with the teams in the project, understand the deliverables as more than just work packages and facilitate success in a project, not just manage the work pacakge and try to obtain sign-off.

The second way is to use the right tools to manage people's expectations and to strike a balance between cost (effort, duration, complexity) and clairty of requirements.

Question Details:--------------------
What has been your largest project management issue from your most successful project?Please share what you believe to be the largest project management issue (positive or negative) you faced during what you believe to be your most important (successful or unsuccessful) project and how you resolved it.

For what purpose do you use a Wiki within your organization?

Internally, we use our wiki everyday and are encouraged to do so as an international organization as it is light-weight and easy to use; whilst being available to the entire company. We tend to keep away from using it for storing project deliverables, but do use it for storing snippets of information about a project - the stakeholders, who's who internally, etc on a project as well as the FAQ's for development builds, releases and testing. For our project artefacts and deliverables, we are using our own bespoke Java applications alongside regular Microsoft products like Office and Project. From a company administration perspective, we use it to keep track of internal initiatives; people's professional experiences outside of our company and their skills (wiki's search capabilities help us find internal knowledgeable resources when we have questions); as well as internal function processes such as expense claims and HR, etc. PS - currently within our organization we use docuWiki.

Question Details:--------------------
For what purpose do you use a Wiki within your organization?How often and for what purpose do you use an internal company Wiki within your Software Development Organization? Do you use it to share knowledge, describe processes, document your developed Software, make plans and estimates, etc. Or do you use another system for such things? Also, which Wiki do you use?

Configuration Management Tools

The team has always used some form of issue tracking and configuration management tool - currently, we are using JIRA to track and manage features, releases, changes and bugs.

This tool has allowed the team to be able to refer back to releases or issues and confidently answer questions posed by the client. If used properly, it represents a key informational cog in the wheel of project and configuration management.

Like many information sources though, it is only as good as the information going into it. Therefore, it is vital to enforce mandatory data requirements to assist in efficient issue resolution.

All of the above are of heightened importance in a distributed project environment due to the ambiguity of informal requirement communication such as email and instant messaging.

Introduction

Hi,

This is the first post. I intend to periodically add articles or notes to this blog to help capture some thinking around the pains, reservations, risks, issues and challenges of distributed development projects as well as the joys, success stories, rewards and gone-wells that myself and the teams I work with have experienced.