Is Google Really a Neural Network?

Firstly, what do we mean by Google? For the purposes of this discussion, we refer to Google as a combination of a search engine and an instantaneous results set across all web site and blog resources worldwide. Now, the last numbers I saw (Feb 2010) estimated 750 million websites worldwide, plus 200 million blogs. There are of course other domains which Google also scans. Other figures suggest 25 billion indexed webpages (Netcraft March 2009).

Here, I use the term neural network not in the strict AI sense, but in a more general sense.

Now, consider the human brain as I understand it (a very simple model). It has a set of data inputs (visual, auditory, chemical – taste and smell, pressure – touch, thermal, inertial – the ear canals, that we know of) and a memory structure. Data input is stored in short term memory becoming information – i.e. brain processing adds context, then sorted and filtered and then moved to long term memory. The short and long term memory takes the form of synapses (junctions between brain cells). More input in a given memory area strengthens the relevant synapses. We know that as we age, the more salient memories (stronger synapses from earlier in our lives) are easier to retrieve, and short term memory becomes less efficient. Our ability to build new synapses falls off with age in most people. Autonomic responses (e.g. breathing) use ‘hard wired’ memory in the hypothalamus which is a very primitive part of the brain structure.

So, consider Google to have a set of data inputs – primarily the bot/crawler data gathering, but also input about the ‘popularity’ of web pages as gathered through use of its search engine by users. The data from these bots about a given web page – for example keyword relevance of content, the number of external links to the page is converted into Google’s proprietary and secret page rank scores and provides a ‘salience’ for the analogous or proxy Google synapse. The proxy synapse is simply (I assume as I am not privy to Google’s design) a database row for the website/page with the aforementioned data items (including the page rank/scoring factors) in the columns, site map entries and site refresh rate and search history information.

Of course the analogy with the human brain breaks down with time, as we would not expect the Google model to suffer from a capacity limitation or by a constraint imposed by ‘technology’ (as happens with the brain when we age and the synapse building processes become less efficient).

So, what use is this analogy to us? Well, consider how we might wish to add to human brain capacity and extend its efficiency - we are getting into William Gibson territory now (he was the author who invented the term ‘cyberspace’). Why plug additional memory chips into the brain, when all that is needed is a connection to Google. Science fiction? I don’t think it is that far away (less than 50 years). The potential social consequences are quite frightening to consider!

This post will be in the context of software development, although the later version of CMM, known as CMMI (‘Capability Maturity Model Integration’) widened the application of CMM to the generalised business process world.
 
Basically, it is a formal certification by an external agency of an organisation’s maturity of process framework – specifically the ability to deliver a software project.

Developed and owned by Carnegie Mellon University in the early 1990s, it was based on real data collected from companies about their delivery performance.

If we consider how software companies grow, then there are clear stages in their development as their level of process sophistication grows and they need to maintain and improve quality levels (one hopes) as their organisational complexity increases. After all, ‘Microsoft’ started in a backyard garage in the 1960’s.

There are five process-related developmental stages recognised in the model:
1. Initial (the backyard garage – typified by a degree of chaos)
2. Managed (typically there are processes in place with defined management – eg project management)
3. Defined (process standardisation is in place, with an organisation process focus)
4. Quantitatively managed (product quality and process performance data is being collected – for example bug insertion rates, individual programmer coding performance – from an ‘engineering’ perspective ).
5. Optimized - process management – the organisation is formally and continually examining the effectiveness of its process performance, and optimising those processes and the ‘learning organisation’ is achieved.
Each of these maturity levels have defined Key Process Areas (KPAs) which typify that maturity level. Further each KPA has five associated definitions:
1. Goals
2. Commitment
3. Ability
4. Measurement
5. Verification
The general nature of these KPAs is apparent and the broader application illustrates the reasons why CMMI was developed to widen application, even as far as ‘People CMM’.
Just as with a human being, an organisation cannot skip a stage (‘miss out adolescence’), although able managers will be able to shorten the timescales.
 
In the explosion of software development outsourcing to the Indian sub-continent, it provided a standardized way of assessing what were basically organisations ‘unknown’  to ‘western’ companies, thereby enabling outsourcing decisions to be made based on objective and independent quality critieria (besides obvious commercial criteria).

However, there is a distinction to drawn. With able (and suitably experienced) management software companies can grow and thrive without the CMM ‘badge’ – for example Microsoft. Whilst not necessarily pursuing formal assessment, the CMM checklists provide managers with a useful way of internally assessing their organisation.

After all, CMM grew out of the US Government’s search for a framework by which to assess potential contractors, and it is in this external delivery context that it is most useful. It is particularly beneficial to software/solutions companies which are delivering one-off development projects. It enables them to promote a maturity level which should give customers a degree of confidence and enables potential customers to compare potential solutions suppliers.

CMM may be contrasted with ISO9001 standards. ISO does provide a gradation of maturity as does CMM. ISO is about a minimum acceptable quality level for software processes. As someone who has worked in organisations under both categorisations (and implemented ISO9001 compliant systems in software houses), the difference to the author is only too obvious. In an ISO9000 accredited company (a customer), a manager once said to me (in somewhat stronger language) – ‘what we make is not of great quality, but its level of quality is consistent and standardized’.

© 2010 Phil Marks

Who’s in Charge – you or the Gantt Chart?

Gantt charts – love them or loathe them! They are a fundamental tool in a project manager’s toolkit. However, an unseasoned project manager can find that they can take over the project and result in reduced control. How so? In this article we will look at their potential pitfalls and provide some tips and strategies for ensuring successful project management. Gantt charts are, after all, just one of many ways of presenting the project planning and actual data that has been input.

Firstly, let us be clear that we are not going to talk about repetitive implementation/rollout projects where a template project plan has been refined over a series of projects and becomes a standard checklist for project management (for example for commercial off-the-shelf software). This paper is about those one off (or initial template try-out) projects. These projects may be within organisations large or small.

Large organisations which have mature and well run ‘IT’ departments may well have formal project offices with established project plan standards, dedicated project office staff and probably automated plan-quality checking systems (for example seeking orphan tasks/missing dependencies and measuring other metrics to provide an overall ‘plan quality’ assessment). Smaller organisations – for example, ‘solutions houses’ - may lack this level of sophistication but will almost certainly require detailed project plans.

Fine, so what is good about Gantt charts?

Well, like most things in life, the returns will be dependent on the investment. So, the more care that goes into the project plan set up, then the better will be the feedback. The danger is that the level of detail that can be built into the typical project plan can itself require a disproportionate amount of project management maintenance. We will not go into great detail here, but dependency and critical path management are of major importance. So, ‘sweating the detail’ in the plan is critical at the outset.

Then, the actual project management overhead can get out of kilter with the budget. What suffers then? An overloaded project management team, under-maintained plan / actual data or both even together.

So, how do we avoid this paradox (aside from unlimited budgets)?

The approach I recommend is based on an initial comprehensive Risk Assessment of a project. We will not go into details here, but the areas to be considered will certainly include:

- organisational readiness and politics
- organisational technology literacy
- organisational staff skills level
- technology proposal
- business risk (eg market issues/competitive pressure and degree of process change required)
- timescale
- rate of business change
- resource including $ availability
- sponsorship weight

This will result in categorising the proposed project as Low, Moderate or High Complexity. Note that a Moderate Complexity project may have a High Complexity phase (and this links back to Contingent Project Management – dynamic tuning of the project management processes).

These levels of Complexity would require differing levels of project management effort set in the resource budget. ‘Rule of Thumb’ would be:

• Low Complexity – project management effort 7-11% of overall resource budget
• Moderate Complexity - project management effort 12-17% of overall resource budget
• High Complexity - project management effort 18-22% or more, of overall resource budget

Now these figures may seem to be inordinately high to some people, but more than 30% of projects are deemed failures – and failure is always the result of inadequate project management (which includes Risk Assessment and Management). So, the ‘buck stops’ at the quality or quantity of project management.

What has all this got to do with Gantt charts?

Simply:

• the plan structure should reflect the prioritised risk analysis with simple milestones / gateways
• the degree of detail built into project plan database should be proportional to the project complexity
• the management reporting requirement should be proportional to the project complexity, thus requiring proportional maintenance.

Then, the maintenance requirement is focused on what really matters. The Gantt charts reflect that, with the degree of detail proportional to the phase risk.

This means that a project manager comes to the office every day thinking ‘How do I move the project forward today towards that milestone’ and not ‘another 4 hours collecting data and 2 hours inputting it before I can get any real work done’.

Then, the project manager’s role’ is mainly one of pro-action and not one of administration.

(c) 2010 Phil Marks

More than 20 years successfully resuscitating and successfully delivering projects in banking, manufacturing and distribution, commerce and government. Find out more at => http://www.projectpdq.com
Phil Marks, MSc, MBA, MBCS, Chartered IT Professional.

What is RUP and Why Use it?

RUP is the abbreviation for “Rational Unified Process” - a systems development methodology  devised by Rational Unified Corporation and now owned by IBM. The author has no connection with any of these organisations, but has used the process framework in major development projects.

The process was developed as a result of work done by Booch, Jacobson and Rumbaugh (affectionately known as the Three Amigos), who were in large part the designers of UML (“Universal Modelling Language). The RUP concept was based on an analysis of what really happens in development projects and why many projects fail (typically the ‘failure rate’ is 30%).

It fits into the ‘Agile’ project management spectrum at the top end, after XP, Scrum and DSDM on a scale of complexity and team size.

By designing the project process in a way which ensures that the riskiest items are addressed according to highest risk first, then the overall project risk (as initially perceived) is not reduced at first, but the risk of a large project gaining momentum and then collapsing spectacularly at a late stage is aggressively addressed. This means that the risk of failure should clearly taper off as a project progresses – this is quite different to what happens in many ‘traditional’ projects. Of course, it will not protect against the risk of a business paradigm shift that has not been foreseen.

Briefly, RUP identifies nine project disciplines:

six ‘engineering disciplines’:
* Business Modeling,
* Requirements,
* Analysis and Design,
* Implementation,
* Test,
* Deployment

and three ‘supporting disciplines’:
* Configuration and Change Management,
* Project Management,
* Environment.

These are supported by software toolsets (for example UML modelling tools, automated testing and test management tools and so on). Iterative working is an essential component of the process structure, with artefacts (in Prince terms these would be called products) being continually refined and retested (remember that even a test plan should be checked against its defined standards, as it is itself a project artefact).

A project is defined in terms of four phases:

1. Inception – this is the high level design of the project itself, including governance, business case, budgets, risks, plans and, often, assessment of an architectural prototype. The exit gateway is called the Lifecycle Objective Milestone – that is, what the project is seeking to achieve over the complete lifecycle (including realisation of the benefits).

Degree of Requirements/Design Changes expected – high
Probability of Requirements/Design Change expected – high

2. Elaboration - this phase involves extension of the teams, design products and prototype buildout, enhancement of project processes (eg testing)  infrastructure, and so on, with a formal exit gateway known as the Lifecycle Architecture Milestone, the passing of which confirms that an executable architecture has been demonstrated which ‘realises’, – that is physically delivers – the architecturally risky Use Cases and how their associated risks are mitigated. It also requires that 80% of Use Cases have been identified and designed, prioritised according to risk, together with rework of the Business Case and Risks. There are other important ‘tangibles’ required at this time too, including the software architecture model and the development plan. At this point the project will move into a phase where the risk profile is raised (relatively) as changes will be more difficult to accommodate.

Degree of Requirements/Design Change expected – moderate
Probability of Requirements/Design Change expected - moderate

3. Construction – in traditional terms, this is where the bulk of the system is built. The exit gateway is known as the Initial Operational Capability Milestone. In other words, at the end of this phase it is now ‘on the runway’.

Degree of Requirements/Design Change expected – low
Probability of Requirements/Design Change expected - moderate

4. Transition – the system moves into production, it is available in beta form to the users and training is underway. It is reviewed against the quality criteria established during the Inception Phase. The exit gateway is called the Product Release Milestone.

Why Use RUP?

The main reasons are:
* The overall project risk profile is front-loaded.
* The technically risky aspects of the system are addressed and proven early in the project. If not, the project is redesigned or cancelled before significant resources are committed.
* Each formal phase has its own inbuilt inception, elaboration, construction and transition phases. After all, the project manager has to ‘deliver the milestones’. This gives the project a ‘fractal’ structure, even down to lowest level programming tasks.
* Testing is a pervasive of the framework process, with proofs/confirmations/reviews a constant theme, so that problems and issues are flushed out as early as possible.
* Because it is iterative, a project can be designed so that a useful prototype may be delivered early (unlike a waterfall approach).
* It is ideal for larger projects which have significant technical risks or are ‘ground-breaking’ in other ways.
* The iterative buildout and incremental delivery approach lends itself to situations where a business area is undergoing rapid change, so that there is early delivery of value, and the shape of the system can be coupled to the rate of change; this however will also require a suitably flexible underlying systems architecture.

How Should it be Used?

It requires a suitably experienced project manager to make it work effectively. It can be applied with a light touch or a heavy touch – the experienced project manager will be able to apply a ‘contingent’ approach and adjust the intensity of the process implementation according to the risk profile, team experience and so on. Indeed, the ability to customise the process is key attribute of a suitable project manager, as the process lends itself very well to customisation.
The Technical Architect, lead analysts, lead designers and test team need to be well versed in the iterative approach.

To be used properly, it will require investment in software toolsets and infrastructure. Given this, the minimum project size at which the process framework becomes practical is probably in the region of 5,000 – 5,000 man days, unless of course an organisation is large enough to share the overhead across other projects.

It is important that the process is well-understood at the highest levels of project governance, as the iterative approach is not always easy to grasp by people who are used to a waterfall structure. Early benefits delivery is nearly always of interest at a governance level.

(C) 2010 Phil Marks. All Trademarks and Servicemarks acknowledged.

Firstly, what do we mean by ‘Fail’?

This has several different meanings in the context of projects, depending on who you ask in the project environment. Some definitions might be:

• project cancellation (reasons will include budget, delay, relevance, strategy change and so on)
• project did not deliver the level of benefits anticipated (but system is still in use). These anticipated benefits might have included items such as functionality, improved customer service and so on, but all ultimately measurable on the ‘bottom-line’. 
• the project cost more than anticipated (but system is still in use) 
• the post-implementation running costs are higher than anticipated (but system is still in use) 
• the project was later ‘going-live’ than anticipated, implying that some earlier benefits were foregone (but system is still in use)

What is the scale of failure?

An oft-reported source is The Chaos Report (1995) by the Standish Group. There is no reason to suppose that things have changed much since then.

• The research showed that 31% of projects would eventually be cancelled .
• 34 % of respondents were very “satisfied”.
• 58 % of respondents were “somewhat satisfied”.
• 8 % of respondents were unhappy with what they got. 
• 40 % of projects failed to achieve their business case within one year of cutover to live operation. 
• The companies that did gain benefits from the projects said that benefits realisation took six months longer than expected (tough to accurately put a number to, as benefits realisation is a flow). 
• Implementation costs were said to average 25 % over budget.
• Supports costs were underestimated for the year following implementation by an average of 20 %. 
• Further results indicated 53% of projects would cost over 189% of their original estimates (but it is unclear whether this is a whole life net cost).

Are these really reasons?

For example, ‘lack of IT management’. Is this a reason for failure? No. The real reason for failure is that:

• There was no effective risk analysis and risk management process which worked (there may have been some risk analysis, even a process, but it patently failed to work).

What about ‘Lack of Executive Support’? Same again.

• There was no effective risk analysis and risk management process which worked.

Indeed, it could be argued that all project failure is due to lack of an effective working risk analysis and management plan.

To be pedantic, a thorough Risk Analysis should include risks that the Risk Analysis may be incomplete, and that the Risk Management process may fail. Hopefully, the associated probabilities will be low.

What if we have an effective Risk Analysis and Risk Management Process - can we still fail?

Yes.

Consider a situation where an unexpected event occurs. For example, company financial issues necessitate a budget cut. The only way that the project can be successfully delivered is that the scope is formally reduced (infrastructure, functionality, organisational scope and so on), assuming that efficiency cannot be increased to cover the shortfall (and if the project manager says that efficiency can be improved, then why was it not being done already)? This might still be seen as failure by some parts of the business if they don’t get their bells and whistles.

Why do projects REALLY fail then?

The main reasons are

 Inadequate Risk Analysis (anticipation) and Control (execution) 

• Lack of visible high level sponsorship and governance 
• Imprecise Objectives
• Poor Planning 
• Poor Communication 
• Poor Requirements Gathering and Change Control 
• Poor Project Management (includes methodology choice, estimating, budgeting, recruitment, monitoring, testing)

These reasons can be boiled down to failure to apply best practice using qualified practitioners. This is often compounded by a failure to take the advice given, but then that goes with the territory when you are a consultant…

Find out more at www.projectpdq.com

(c) 2010 Phil Marks. All Trademarks and Servicemarks acknowledged.