Here is a list of the main reasons for MOSS project failure based upon experience (many reasons will also be applicable to non-MOSS projects). Other (occasional) reasons contributing to failure include inadequate business domain understanding, MOSS deployment design and MSFT licensing appreciation but for the sake of focus, only the main reasons are shown here. Reasons are shown in descending priority order:
1) Scope management. Initial requirements gathering insufficient. Incremental scope additions undocumented and outside change management. Little or no architectural analysis of scope shifts before they are implemented resulting in downstream performance, testing and hosting integration issues. High-Level Design (HLD) used as sole written basis for development. HLD is generally insufficient for developers to interpret and develop against. A solution can be to factor in element of client MOSS training during the early analysis stages. This will reduce incidence of client scope expectation being significantly more advanced than what is possible Out-Of-the-Box (OOB). Basically, clients tend to think MOSS can do more than it can - OOB.
2) Configuration management. Robust problem and change management processes missing; inadequately defined or not maintained. Doubly important in a MOSS environment where configuration, content and code (and also data and process) are entwined. Effect of this is that developers become confused as to what they are supposed to be working on and client loses detail visibility. Senior developers may attempt to establish these processes but will generally be ineffective due to inexperience and their relative capability for enforcement. Multiple versions of both requirement and design documents stored in multiple places and little attempt at sign-off coupled with poor client communication means that entrenched positions are swiftly made. Developers can struggle with the same issue for days. If daily updates are recorded in a problem management system, this will be obvious to the Project Management (PM) function through oversight.
3) Project communication. Poor overall project communication. With a focus on gaining hard MOSS technical skills, softer skills such as communication are often overlooked. Developers typically send conflicting messages to client. No team scrums, little articulation of cause and effect in terms of project plan. No “bottom up” captures or extrapolation. Culture of sharing information not engendered at senior developer level. PM reporting limited; when requested at high level and non-specific.
4) Skill levels. Due to initial shortages of MOSS skills, developers have historically been staffed to projects with the effective remit of learning on the job. This is not now the issue it used to be due to wide-scale MOSS training focussing on .NET Web part Framework. There remain key poorly resourced areas e.g. workflow and InfoPath development and engineering experience in MOSS “lockdown” mode.
5) Administrative duties. Not really focussed on operational logistics e.g. reporting status, ensuring adequate vacation cover, maintaining a service incident log, ensuring network access for resources and providing a view to scheduling on upcoming resource requirements. In a market where MOSS resources are relatively scarce, focus on effective resource management is critical.
6) Engineering resource. Insufficient engineering resource can be applied to MOSS projects. This manifests itself as generally assumed acceptance of the client infrastructure and hosting plans and means the team cannot plan and iterate for performance from design onwards.
7) Client relationship. Diminished client relationship. This can be left by default to be built by developers. Without a consistent face being presented to the client through reporting or solution walkthrough, the possibility for a relationship to grow is diminished and client finds it easy to take an aggressive stance to the engagement when required. This is particularly important where a RAD approach is more applicable e.g. MOSS.
31 March 2010
21 March 2010
BI Strategy Planning Tips – Part 1
Planning a BI strategy for your organisation can be challenging; you need decent industry/vendor awareness, an appreciation of organisational data and ideally; a handle on budgeting. In no particular order, here are some practicable tips to get started with yours. More will be forthcoming.
1) Start with your Supply Chain. Reduction of energy use in data centres is a key IT issue. This is generally driven by either a cost saving drive or a Green IT focus (shouldn’t they really be the same thing though?). However, most organizations budget between 2-5% of revenue for IT budgets, yet spend roughly 50% of revenue on all aspects of supply chain management. Basically, there are significantly more savings to be made in the supply chain than in data centres. Large volumes of raw data are generated and stored by each process of the supply chain (plan, source, make, deliver and return) by automated enterprise applications being used at most large, global manufacturers. BI can help determine what information is necessary to drive improvements and efficiencies at each process in the supply chain and turn the raw data into meaningful metrics and KPIs.
2) Forget the BI-Search “evolution”. Just the training costs for commercial BI systems are expensive. Organisations want single (easy and simple) interfaces wherever possible and a search-based interface appears to be the key to engaging the masses. There has been heavy speculation over the last couple years (ongoing) that BI and Search technologies will somehow merge. This approach however only really surfaces existing BI reports for more detailed interrogation e.g. “July Sales Peaks”. A search string is not a rich enough interface to support ad-hoc queries. Think about it? You need either a devoted language e.g. MDX or a rich data visualisation package to traverse dimensional data. A search box will never explore correlation between marketing budget and operating income.
3) Forget “BI for the masses” (for now). BI has been actively used in the enterprise since the early nineties. The expectation of “BI for the masses” (basically - the SMB market) hasn't exactly happened. Why is this? It’s because people want to collaborate and jointly come up with ideas, solutions, figures and approaches. They need this for personal, political and commercial reasons. It will change when enterprise SOA is in place and it might change when there is a change in the way consumer impacts enterprise networking. It will not change in the short-term.
1) Start with your Supply Chain. Reduction of energy use in data centres is a key IT issue. This is generally driven by either a cost saving drive or a Green IT focus (shouldn’t they really be the same thing though?). However, most organizations budget between 2-5% of revenue for IT budgets, yet spend roughly 50% of revenue on all aspects of supply chain management. Basically, there are significantly more savings to be made in the supply chain than in data centres. Large volumes of raw data are generated and stored by each process of the supply chain (plan, source, make, deliver and return) by automated enterprise applications being used at most large, global manufacturers. BI can help determine what information is necessary to drive improvements and efficiencies at each process in the supply chain and turn the raw data into meaningful metrics and KPIs.
2) Forget the BI-Search “evolution”. Just the training costs for commercial BI systems are expensive. Organisations want single (easy and simple) interfaces wherever possible and a search-based interface appears to be the key to engaging the masses. There has been heavy speculation over the last couple years (ongoing) that BI and Search technologies will somehow merge. This approach however only really surfaces existing BI reports for more detailed interrogation e.g. “July Sales Peaks”. A search string is not a rich enough interface to support ad-hoc queries. Think about it? You need either a devoted language e.g. MDX or a rich data visualisation package to traverse dimensional data. A search box will never explore correlation between marketing budget and operating income.
3) Forget “BI for the masses” (for now). BI has been actively used in the enterprise since the early nineties. The expectation of “BI for the masses” (basically - the SMB market) hasn't exactly happened. Why is this? It’s because people want to collaborate and jointly come up with ideas, solutions, figures and approaches. They need this for personal, political and commercial reasons. It will change when enterprise SOA is in place and it might change when there is a change in the way consumer impacts enterprise networking. It will not change in the short-term.
18 March 2010
You can tag. A lot.
(Originally posted 1 May 2009).
MSFT Tag is a Windows Mobile application that uses the device’s camera to recognize a graphical image or tag for the purposes of obtaining information. You could print one out as a sticker and place it on a landmark to get a link to its site or Wikipedia definition for example. Each tag consists of a 5X10 grid of triangles (although these can also be smaller circles; overlaid over a background image to create a custom tag), each of which can be in one of four colours. This allows a tag to hold thirteen bytes of data. Information received is of four types – URL, Telephone number, Vcard and free text.
Telephone numbers, text and URLs (with a bit of compression) could maybe resolve from the device i.e. the tag itself stores the URL and the device either directly calls the telephone number or jumps to the URL/displays the text. QR codes work in this way. This is disproved however when a device is switched to “Airplane Mode” and tag recognition just does not work. This means that MSFT Tag on the device jumps to a proxy server that resolves the reference (GUID) extracted from the tag into the information already uploaded to the MSFT Tag site. The proxy servers must be pretty impressive as the whole thing works very smoothly.
Thirteen bytes is enough to store a number of 2.02E+31; each one referencing a separate piece of information. This is broadly comparable to the number of grains of sand on all of the beaches of the Earth so MSFT must be expecting a decent take-up of this.
Tags are really useful for URL links that contain filters tied to a geography in the link e.g. you are at a bus stop and there is a tag that shows bus schedules; whether they’re late or not – for that particular stop. Vcards, Telephone numbers and free text are cool rather than essential e.g. you might use a tag embedded into a colleagues’ email sign-off to get their details into Outlook but it’s never going to be a killer application.
MSFT Tag is a Windows Mobile application that uses the device’s camera to recognize a graphical image or tag for the purposes of obtaining information. You could print one out as a sticker and place it on a landmark to get a link to its site or Wikipedia definition for example. Each tag consists of a 5X10 grid of triangles (although these can also be smaller circles; overlaid over a background image to create a custom tag), each of which can be in one of four colours. This allows a tag to hold thirteen bytes of data. Information received is of four types – URL, Telephone number, Vcard and free text.
Telephone numbers, text and URLs (with a bit of compression) could maybe resolve from the device i.e. the tag itself stores the URL and the device either directly calls the telephone number or jumps to the URL/displays the text. QR codes work in this way. This is disproved however when a device is switched to “Airplane Mode” and tag recognition just does not work. This means that MSFT Tag on the device jumps to a proxy server that resolves the reference (GUID) extracted from the tag into the information already uploaded to the MSFT Tag site. The proxy servers must be pretty impressive as the whole thing works very smoothly.
Thirteen bytes is enough to store a number of 2.02E+31; each one referencing a separate piece of information. This is broadly comparable to the number of grains of sand on all of the beaches of the Earth so MSFT must be expecting a decent take-up of this.
Tags are really useful for URL links that contain filters tied to a geography in the link e.g. you are at a bus stop and there is a tag that shows bus schedules; whether they’re late or not – for that particular stop. Vcards, Telephone numbers and free text are cool rather than essential e.g. you might use a tag embedded into a colleagues’ email sign-off to get their details into Outlook but it’s never going to be a killer application.
Subscribe to:
Posts (Atom)