Blog

MoSCoW calling!

I have very much enjoyed writing these blog articles for SkillSolve who have very kindly given me a platform to trawl through my work experiences and formalise and map them into something I hope is useful.

One of the previous postings was regarding AGILE and SCRUM and Prince2. The posting looked at where they could be of benefit to each other. AGILE complements Prince2 by adding a layer of value between the Project Manager and Team Manager involvements. Prince2 positively avoids any detail surrounding how teams should be managed and planned. AGILE brings some new ideas into this gap by introducing scope tolerance mechanisms and the need to prioritise requirements. The previous posting brought forth some great comments. So I thought I would dig deeper and see what other parallels I could find.

A couple of years ago I was fortunate to be involved in a piece of consulting for a large UK insurer. The work involved analysing the products in the Learning Management Systems (LMS) market for feature, function and suitability. An LMS is used to catalogue and deliver e-learning content, track usage by user/material/date etc and generate reports. Depending upon the functionality being sought, these can be significant learning investments. At that time, there were over 60 LMS products to analyse. A partner and I split the offering alphabetically and then proceeded to analyse the features. We then colour coded the products based on feature and other commercial criteria such as company size, market share, credibility and credit rating(solvency). Assuming we had got the customers profile fully understood, we felt that we had reflected the products that would be the best fit to the customer … or so we thought!

When looking at the product features, we used the MoSCoW prioritisation method with the client. The method is attributed to Dai Clegg of Oracle UK in 1994. It has been made popular by the Dynamic Systems Development Method (DSDM) community but also is used as complimentary guidance in product selection by those adopting the ITIL framework (ITIL Service Design). We used it to assist in product selection. However it is also used when defining the objectives and requirements of a project.

The mnemonic MoSCoW, when prioritising requirements, stands for:

M – Must Have – Those requirements which non-negotiable and must be provided by the product produced by the project.
S – Should Have – Those requirements which should be delivered. They could be omitted, but should be included if possible.
C – Could Have – Those requirements that are less critical to customer acceptance. “Nice to have” but not essential.
W – Won’t Have – Those requirements that are the least critical to customer acceptance. These will tend to be delivered later.

When one begins identifying the four categories, it is worth spending time considering the relationships that exist between requirements. You can’t make a cup of tea without water. As one requirement is classified as Must Have, so there may also be others that also need to be classified in a similar way. We found that there were implied requirements – some may view these as constraints – but they formed part of the overall deliverable. Understanding these dynamics is important and crucial to planning.

On paper it could appear a little extreme having all items categorised as Must Have. It is possible and it creates another set of problems in a project in the sense that there exists hardly any scope. Resolving this needs agreement from the customer, the project manager and the relevant delivery teams. Unless a requirement is a clear Must Have, its categorisation should be challenged. The onus is then on the customer to justify why it is a Must Have. If they are unable to achieve this, then these requirements should be categorised as Should Have at best. The customer needs to appreciate the impact on the project of having nothing but Must Haves in their requirements list.

In our research we had a customer who wished to be kept in the loop with our preliminary research. The issue it caused was that the customer began to think they had under-specified their requirement. The dynamics of the e-learning marketplace as there were in 2001 were fast moving with mergers and standards emerging. Our solution to this was to give the customer an extended recommendation list. Rather than the top three products they asked for the best ten – but our analysis would focus on the core and emerging features. Then they would confirm the Must Have requirements internally before commencing the project. For us MoSCoW was an iterative practice to agree a stable product description and produce a viable business case off the back of it.

So what is the right balance of Must Haves compared to other categories. Must Haves are non-negotiable. Therefore anything else represents flexibility which you will need in your project. Realistically you should aim to keep the percentage of Must Haves as low as possible. For me personally, if the percentage rises above 50%, then you need to understand what risks you face and manage those risks well whilst ensuring all estimates are validated and well understood.

MoSCoW is not rocket science but it is an essential aspect of project definition. Before utilising timebox planning – which we will look at in a later posting – it is vital that a Prioritised Requirements List (PRL) is developed.

Additional references:
www.dsdm.org
ITIL Service Design – Colin Rudd and Vernon Lloyd – OGC TSO – ISBN: 978-0113310470

Posted November 3rd, 2009 by The Dark Knight in SkillSolve | Comments (0)

PRINCE2, AGILE, SCRUM – are they connected?

As some of you are aware, apart running projects, I also teach. The two areas I mainly specialise on are ITIL and Prince2. I do enjoy bringing real world experiences into the classroom. It adds a lot of credibility to the messages you are conveying but also adds to your standing, as a tutor and mentor, in the eyes of the delegates. They do not want someone to quote the book and roll out the banter week in week out. They want to learn what does and does not work in reality or, as is the case over 90% of the time, what do you have to alter or tweak.

Teaching is bit like Marmite. You either love it or hate it and likewise delegate’s reactions towards you can be similar – they either take to you or they don’t. You do occasionally get the odd delegate who doesn’t like anyone. They sit apart from the others, they don’t speak unless spoken to and generally they are avoided by all – sometimes even the tutor finds it easier to stay quiet too. That’s life folks! However you do get the odd delegate who wants everyone to know them. In particular how much they know in relation to others. Are they insecure? Are they corporate bullies? Who knows? However they do lie in wait in the classroom – hoping to “put someone in their place” or better still make the tutor look stupid or lacking in knowledge. Such people do exist and sadly yours truly met one a few months ago.
“How does Prince2 relate to Agile?” “Where is Prince2 in relation to Scrum and XP projects?” “Have you seen any lessons we should be aware of?”

Three questions fired at me without drawing breath. A little sardonic smile at the end of the tirade!

Now I had a small dilemma. On these topics, I knew a little, but not a lot. Waffling is always out of the question.  So I write the three questions on the whiteboard and say as all people when they feel caught in a corner “I’ll come back to you with an answer”.

So off they go and have a go at the main Organisation question. I’ve got 40 minutes and an internet connection. What more do I want? What I found was the following.

Prince2 has been the dominant project management method in the UK  for a number of years and one of its strengths is its emphasis on control. One key control is the product description where you define what you want producing before any work is performed. That does not work for everyone as it can impose a rigidity that is alien to the way a lot of people work. Software development prefers a more “agile” approach. Outcomes are defined in advance yet the route that is taken to achieve those outcomes may need to be very flexible. An example that is often quoted in support of Agile is the Toyota Prius. Toyota didn’t set about designing a hybrid-engined car. Instead they set about designing a car that could achieve 55 mph. The route they took in achieving that outcome was to develop the Prius. So the story goes.

So what is Agile? Agile is the term associated with the DSDM project delivery framework. DSDM stands for Dynamic Systems Development Method. Since 2006 this method has become free to use. DSDM is an Agile project framework, with guidance, to achieve on-time and on-budget delivery to satisfy a business objective. In a nutshell DSDM looks at the product delivery side of a project in more detail and allows for greater flexibility. Prince2 as we all know does not. Prince2 deliberately avoids any detailed discussion on the mechanics of product delivery.

So how do Prince2 and DSDM fit together? On the face of it they are a natural fit. Both approaches make use of product descriptions and in terms of their organisational structures (Project Board-Project Manager- Team Manager) they are very similar. Such similarities also cuts down on duplication. DSDM adds to Prince2 in the following ways.

DSDM introduces scope tolerance mechanisms. Time, cost and quality are fixed – there is no tolerance available. Which may turn traditional thinking on its head, but in reality are these not fixed in the mind of the customer already? What DSDM does offer is flexibility in terms of the features (scope) being delivered in the products via Prioritised Requirements List (PRL) which in turn is controlled through the use of techniques such as “MoSCoW” and “timeboxing”.

DSDM promotes iterative and incremental product development. On projects where the final project product is complex, this is essential. This means that DSDM can deliver parts of a project sooner in the project but also can deliver ROI (return on investment) earlier than may be considered in a Prince2 project.

DSDM organisational team structure goes lower down than the Prince2 equivalent by adding additional customer and supplier roles which operate at the production level. These additional roles map quite easily into the Prince2 organisation.

The DSDM style of delivery encourages greater collaboration which in turn enhances the speed of communication between the roles as well as providing for a greater understanding of what the products are to deliver. This is described as enabling an Agile ethos. This ethos may not sit well with traditionalists but it does deal with the fact that detail emerges during a project which will prompt change that is handled dynamically within the project. This detail and change requirement will not have been foreseen at the outset of the project. However, is this not what happens in reality?
DSDM provides a more effective communication engine. Facilitated workshops are used throughout to create fast lines of communication, understanding and ownership. The supporting documentation is more graphic than text based with the intention of simplifying messages and reducing misinterpretation.

So Agile or DSDM is a complement to Prince2. It addresses issues of product creation that are not covered – indeed avoided – by Prince2.

So what is SCRUM? Well as a rugby term it is defined as “the mechanism in a game of rugby for getting an out of play ball, back into play”. If one considers the ball to be a project or a product, you can quickly see the connection. In method terms, SCRUM is, at its simplest, an implementation of DSDM. SCRUM operates at the Team Manager level and prescribes a number of roles which specific responsibilities such as Product Owner, SCRUMMASTER, Team Member. Scrum adds guidance in product production where Prince2 does not.

XP projects? Well, these are another form of Agile implementation. XP stands for Extreme Programming and closely associated with software development andit advocates frequent “releases” in short development cycles. Just like SCRUM it is intended to improve responsiveness to changing customer requirements – an inevitability in all projects.

So in a nutshell, Prince2 offers great control at the project level. Agile brings direction and freedom and “agility” at the production (team) level – an area Prince2 avoids in detail. SCRUM and XP are implementations of the Agile approach at the team level. This may be too simplistic for some peoples taste, but it demonstrates how the concepts relate to each other.

I got back to my delegates with the summary. Mercifully no further questions came back, but he has made me buy a book on Agile.

Resources Used:
http://www.dsdm.org
http://www.best-management-practice.com/gempdf/DSDM_White_Paper_v2.pdf
Agile project management: running PRINCE2 projects with DSDM Atern (Paperback) by Keith Richards ISBN 0113310587
Agile Project Management with Scrum (Microsoft Professional) (Paperback) by Ken Schwarber ISBN 073561993X

Posted October 7th, 2009 by The Dark Knight in SkillSolve | Comments (5)

Prince2 2009 – What’s the difference?

In June 2009, the Office of Government Commerce launched a new edition of the Prince2 method. Many organisations have previously invested heavily in Prince2 and will have been wondering what the key differences are and whether they offer any real benefit. In this posting, I will look at the key differences between the 2005 and 2009 versions of Prince2 and then from my own perspective offer a view on whether I feel they offer any advantages.

The most noticeable difference between the two manuals is size. The 2009 edition is over 120 pages lighter than the 2005 version. Less is definitely more as we have greater consistency in the terminology. The 2005 edition was once likened to a FIAT Multipla on one of my courses. As that was our family car at the time, I enquired how such a conclusion was reached. “Well Jeremy Clarkson described it on Top Gear as being designed by a group of people who have clearly never met each other”. I found this hard to refute. |You cannot level such an accusation at the 2009 edition – it is much more polished and complete.

The first structural change we notice in the 2005 edition of Prince2 is that Principles are a lot more prominent. In the 2005 edition they were implicit – distributed across the book and often repeated and paraphrased in a manner that is best described as inconsistent. In the 2009 edition Principles are explicit and are an integral part of the method.

Components in the 2005 edition have now been renamed Themes and they have reduced in number – only by one.  I have always described components as sub-appendices of detail that support the processes. In the 2009 edition, the themes now precede the processes. This makes a lot more sense as the processes use the themes. What makes even more sense is merging configuration management into the Change theme so we now have seven themes instead of eight components.

The processes have been altered too. We now have seven processes. Planning in the 2005 edition is now part of the Plans theme in the 2009 edition. The best change by far for me has been the abolition of the sub-process shorthand references such as SU1, DP2 etc. We now have activities in each process with names that are more meaningful but also capture the essence of Tailoring Prince2. Scalability of the processes in the 2005 edition is now replaced by a chapter dedicated to considering how much of the Prince2 method is actually required of your project.

There are less management products – eleven fewer no less. This is also a change for the better. Every project I have worked on – and I’ve worked on a few! – has never used the same documentation in terms of content – there is always some alteration or addition that is designed to meet the host organisations explicit needs. Once again the essence of Tailoring Prince2 is being re-enforced. Where the 2005 edition came across as being prescriptive, the 2009 edition encourages context to be considered at all times.

One area that I used to enjoy teaching the least (think about it) in a Prince2 course was the techniques, especially Product Based Planning. Techniques by their very name imply personalisation – “skill in some specialised activity” is how the Oxford English dictionary describes a technique. Did we really need over 25 pages to tell us how to work out what the project was producing? In the 2009 edition, the techniques are still there. Product based planning is much more concisely explained. Companies have always had their own method for change management and accepting products. With this in mind Quality Review and Change Control are shown as complementary guidance. In fact Prince2 encourages using the appropriate body of knowledge to get the best results i.e. M_o_R for risk management, MSP for programme management and ITIL for service management. Recognising that there are other, better qualified and specialised bodies of knowledge out there, enhances Prince2’s credibility.

So – is it any better? The proof as they say will be in the eating. One of the biggest misunderstandings – if that is the right word – with the 2005 edition is that on too many occasions people have tried to follow the book – creating management products with the same names and content as the management products in the manual. That was not what was intended. It was always the application of the message, never the method. The 2009 edition has gone one step further in re-enforcing that message with the emphasis on Tailoring Prince2. Once people move away from seeing the method to seeing the message, then we shall see the true value of Prince2.

Posted October 7th, 2009 by The Dark Knight in SkillSolve | Comments (2)

What’s in a term?

“Why is it called a pie chart?”

I was dumbstruck. Here we were at four pm on the second day of a training course looking at the capabilities of Lotus Freelance graphics. We have been working with data for two days, representing it in so many different formats – Bar, line, Bar-Line, Area – you name it, we graphed it – including the Pie-Chart. Here at the end of the course, I get this question.

My first thought is “Has anything gone in?” The lady has asked this question in all seriousness. Behind her a group of young lads are grinning like hyenas that have just detected a nearby prey. I give them my sternest look – as stern as any wounded animal can muster. They calm down – I am still numb. I explain why it’s called a pie chart and pray for the course to end – soon.

Later a colleague walks into my room and asks how things went. “Great group” I said. But you would never believe what I was asked at the end”. I tell him. He laughs. I laugh – now. “This happens to me all the time” he says. “I assume that they know more than they do and they never fail to let me know that they don’t – never assume, they’ll make an ASS of U and ME”.

Training can be cruel, but the lesson I learnt back in 1991 has been with me throughout my various roles since – Never Assume.

Today I still teach part of the time. I teach ITIL, Prince2 and get involved with technical projects are Lotus Domino (usually migration) in either a team or PM role. The lesson still applies.  Even on Prince2 training courses, assumptions are made that need to be corrected. How much work do you have to put in? How much pre-course reading will they have done? Prince2 courses are not an easy ride! The reward is more than worth the effort.

In the early part of this century I was heavily involved in a lot of e-learning projects focussed around IBM/Lotus products – LearningSpace in particular. My role varied from being technical through to product consultancy through to content creation. We had a deployment method based loosely around Prince which was documentation based and supplemented by meetings. One such meeting was a Discovery Workshop where subject matter experts (SMEs), stakeholders and other players would be given the opportunity to put forth their views on content and interaction.

Now I don’t know if it was down to lack of familiarity with the learning environment or the concept of e-learning or downright insecurity, but there were a number of times when I and a colleague had to ask people: “Could you explain that for our benefit please?” or “Can we just clarify your use of that term?” They looked at us as if we had two heads, all naturally assuming we knew exactly what they were talking about. The bigger the acronym, the more we asked. I suddenly found myself wondering “Why is it called a pie-chart?”

This could not be allowed to carry on. So this is what we did. After a short break and the focus of control switched back to us, we split the people up into groups mixing customer and supplier where we could. We then set a short five minute task to come up with as many terms as they felt were relevant to the project. For example “What you understand by the terms: content, compliance, LMS”. We then consolidated the terms on the board – nothing was ruled out. When a term went up on the board we would then ask someone from a different team to explain what it meant. This way we would be more likely to get collective agreement and sometimes we didn’t!! We also bravely tackled some of the management-speak that had been floating around the room. Terms such as “Effective” and “easy to use” were explored.  As I was writing on the board, my colleague was documenting these as part of our project definition which we fully intended to get the customer to sign-off. We also gained a useful insight into the customer with this exercise. There were quite a few places where they themselves had wrongly assumed a terms meaning.

So what is the relevance to Prince2? Prince2 makes reference to assumptions in the Project Initiation Document (PID) – the main working document for the project. It is logical that assumptions regarding term definition should be included here. However there may be certain matters of confidentiality that prevent it being shared with suppliers. I am sure you can all think of items that should remain within the remit of the customer. In our case, this was not an issue with this particular customer but it is not a universally open document. So to be consistent and fill the gap between PID and supplier, we created a Key Terms Definition (KTD) document. The KTD listed all agreed technical and assumed terms between the parties. There was a consensus on the terms, their meanings and application. It was about two sides in length and it was requested that it be subject to strict control (formal change and configuration management). As we became more involved in e-learning projects, the KTD became increasingly central to our engagement. It helped in empowering stakeholders and players, but also reduced some of those horrible exposures that can crop up in handover and review. It was more significant than a glossary – it was a small control and it worked.

Anyways, in case some of you are wondering “Why is it called a pie-chart?” Well it does look like a pie!

Posted October 7th, 2009 by The Dark Knight in SkillSolve | Comments (0)

The importance of being measurable.

“But I’m not on the X-BOX!”

How many parents have heard those magic words before, I wonder? My son is fifteen years of age and like most of his peers with a games console, they seem to be surgically attached to these infernal devices twitching involuntarily every so often and grunting into a headset to their friends after some “brilliant or ACE manoeuvre”.

“But you are” I retort. “You have the hand thing in your hands, the headphone thing in your ears and something very horrid on the screen!”

He detaches himself and shows me a screen that logs his time on X-BOX Live! It backs up his story that he wasn’t on the X-BOX. X-BOX Live! Is what the console is about, so I am told. I leave the room – I have no will to argue and more importantly only subjective assertions which his “totally objective X-BOX Live!” log will refute. I go and tell my wife – out of concern for lordship but also I will not be beaten!

“This just like that project you took over last year” she says. This was not the sort of support I was looking for. The project she was referring to was a nightmare. It was to deliver several e-learning modules for a council extranet. I took over from a PM who was leaving, there was a new customer project manager coming in, the budget was gone and the delivery dates were no longer achievable. Add in to the mix the fact that the documentation was “thin” in places – it really wasn’t a nice place to be.

Both parties clearly wanted out of the project. It hadn’t been well defined or executed. Such projects do exist!

The only stumbling block that I had to getting closure – and more importantly the client to sign off the last invoice – was a statement that was made in the initial brief about the courses being “more effective than their classroom equivalent”. That was not an unreasonable request. Why would you commission something less effective that what you already had? Would that make for a viable business case? Hardly. Both I and the customer project manager were Prince2 practitioners. The thought going through both our minds, we admitted to each other later was, “How can/do we demonstrate effectiveness?”

Prince2 makes a clear statement in this regard when assembling the Project Brief (2005) and the Project Product Description (2009). You should capture the Customer Quality Expectations (CQE) – which is what “more effective than their classroom equivalent” represented. However there were no Acceptance Criteria (AC) detailed – those measurable definitions of quality that are used and combined to indicate customer acceptance. When I teach Prince2 courses I always differentiate ACs as being the “black and white” aspects of quality – they are or are not proven. CQE I talk of as being “grey” or aspirational aspects of quality which are significant for the customer and that they need clear definition as part of the AC.

Both of us – the customer PM and myself – agreed that a pre and post survey of a new group using the updated materials would be the best approach. We drafted a questionnaire document which assessed an employee’s ability to perform certain tasks before using the training materials. We then interviewed a sample group and conducted a paper based survey of the remainder of the pilot group asking closed questions in each instance which created an overall weighted index. We needed something measurable which we could use to prove our agreed definition of “effective”.

The results were better than I expected to be honest. The ability of employees to use certain systems was measurably faster, their awareness of certain key information stores was enhanced and overall they felt pretty comfortable with the content. There were areas of weakness too, but the overall conclusion – backed up by empirical data – was that the course materials were more effective than their classroom equivalent.

We both had what we needed to close the project amicably – yet not profitably. We both also felt that if the key Prince2 message of understanding and proving quality from the customer perspective as well as the supplier’s had been effectively documented and agreed from the beginning, the project could have yielded a more positive outcome.

Posted October 7th, 2009 by The Dark Knight in SkillSolve | Comments (0)

Not a Course Booking Agency?

Our pricing is so competitive, delegates often ask us if we are an agency.  We are a training company and have been delivering our own courses with our own trainers for over 15 years.  We believe that we offer the best value for money in the marketplace.  In this current economic climate, it is even more important to offer the lowest price possible for training courses.  We are able to do this by keeping our company overheads as low as possible whilst maintaining the highest possible level of customer care.

Posted July 21st, 2009 by John Smithson in SkillSolve | Comments (0)

PRINCE2 2009

PRINCE2 2009

Why has PRINCE2® been updated?

PRINCE2® has been updated to reflect the latest best practice approaches for project management.  Since its launch in 1996, there have only been two major updates (in 2002 and 2005) of PRINCE2.   The method itself has remained largely unchanged, this is simply a routine update to the product.
The refresh is being led by the UK’s Office of Government Commerce (OGC) and involves OGC’s two main partners for its Best Practice portfolio: TSO, the official publisher and the APM Group, the official accreditor.

Should I take PRINCE2 (2005) now or should wait for PRINCE2:2009 to be released?

There are no major differences between the 2005 and 2009 versions of PRINCE2 – the methodology has been refreshed and not re-written so we would recommend that you do not delay your training or exams until the 2009 version has been released.

What will the format of the new exams be?

Information on the format of the PRINCE2: 2009 exams can be found at www.prince-officialsite.com/Qualifications/QualificationScheme2009.asp

2009 Foundation Examination

75 questions per paper
5 questions to be trail and not counted in scores
35 marks required (out of 70 available) to pass – 50%

2009 Practitioner Examination

Objective testing examination
9 questions per paper with 12 marks available per question, all question items will be worth 1 mark, making the total number of marks available 108
2.5 hours allowed (no reading time has been added)
Open book exam (manual only)
The pass mark is 55%.  Candidates will need to achieve at least 59 out of the 108 to pass the examination.
Important Note on the Pass Mark: From 6th July 2009 the pass mark for the Practitioner exam is changing from 50% to 55%, for papers based on either the 2005 or the 2009 editions of Managing Successful Projects with PRINCE2.

Re-Registration Examination

For information on the new Re-Registration Examination, please visit www.prince-officialsite.com/Qualifications/ReRegistration2009.asp.

When will PRINCE2® (2005) exams be retired?

The 2005 exams will be withdrawn on 31st December 2009.

Will my Foundation / Practitioner qualification still be valid upon PRINCE2 2009 being released?

As is the case now, there is no expiry date for your Foundation qualification but all Practitioner qualifications have to be re-registered after five years be kept them current.

What is the difference between PRINCE2® (2005) and PRINCE2®:2009?

The overall structure of the method remains largely unchanged and now includes 7 Principles, 7 Processes and 7 Themes.  The 7 Principles are key to ensuring that you are carrying out best practice project management.
The Processes have remained similar.  The Planning Process has been moved into the Plans Theme (previously known as the Plans Component).  Otherwise the Processes remain from Starting Up A Project (SU), through to Closing A Project (CP).  The diagrams have been updated to show a simpler view of how each process works.  The most significant change is that the Sub-Processed have been removed (i.e. SU1, SU2, SU3, etc).  The activities within each of the processes are still there, but are not numbered.  The result from this approach is that the processes appear less prescriptive in respect of what order to do things.

The 7 Themes are essentially the Components from the 2005 version of the manual.  There has been extensive work carried out to update the advice and approaches for the Themes, particularly in the Management of Risk chapter.  The old Configuration Management Component is now included in the “Changes” Theme.

Will my investment in PRINCE2® (2005) publications and training be lost?

APMG do not expect that any investment in training on previous PRINCE2® versions will be lost as it is still a valid and productive methodology for the management of projects.  The refresh of the manual is exactly that, a refresh to update and make improvements to the methodology – not to re-write it.  Therefore there is no danger of PRINCE2®:2005 being considered outdated or invalid.  Users of the 2005 version are under no obligation to update to the 2009 version.  The only time a candidate will be required to learn about P2:2009 is if they wish to take the Re-Registration exam after the launch of the new manual.

Posted June 24th, 2009 by angelabradley in SkillSolve | Comments (0)

Public Sector Discounts

We are offering extra discounts on our normal prices for all Prince2 Foundation and Practitioner courses, and also on all ITIL Foundations courses.  Please contact us for more information.

Posted February 25th, 2009 by John Smithson in SkillSolve | Comments (1)