Category Archives: Uncategorized

Separated by a common language... IT English is different

I am not a stupid person, but I simply cannot keep up with all the new information technology (IT) terminology!

I know that every industry has acronyms and terms, but it seems that IT artifactis unique: every time a new methodology comes in, English words are redefined.  Today, IT English is expanding.

For example IT English uses Scrum (but not for rugby), Ruby (not for birthstones), Java (without caffeine), and Artifacts (but not from Egypt).  Certainly, English English is different from American English and Australian English, but IT English is a dialect unto itself.

If I, as an engineer with experience in IT, am daunted by the ever-changing IT English, how much worse is it for laypersons who work on software projects?  It can be intimidating.

I read an “introductory article” written by an IT colleague today and had to read and re-read it several times before I gave up. Despite visual aids and process flows, I felt I needed a geek-to-English dictionary to make sense of it.  (Yes, it was written in English.)

Most of us are not bilingual, so it should be no surprise that many technology professionals only know IT English. In fact, some do not even realize that there are other English dialects. When engineers find a new way to do things, you can expect a flurry of new acronyms and variations on IT English.

This happened with “waterfall”, client/server, web development, agile, lean, and Kanban. Once you understand that old words get new meanings, it all makes sense, but it is a learning curve every time.

Do you know that everyone (outside of IT) asks

Why can’t IT just speak English?

Outside IT, it’s no mystery why software projects fail (to meet user needs).  Just when users and the business learn enough IT English (technology) words to converse, a new method comes in and the dialect changes.

In my post earlier this week (IT’s all about the people, stupid), I touched on the need for “soft skills” in technology, and mentioned the communication factor.  Soft skills or EQ (emotional intelligence quotient) covers more than communication (such as empathy, consideration, mutual respect, cultural sensitivity, communication, and a host of other people skills), but communication is the linchpin.

My first IT English “encounter”

I’ll never forget my first engineering job in Alberta, Canada working for a pipeline engineering company. During the first week, a colleague suggested that I should “sign on” to the mainframe.  I gave him that “are you nuts – why would I want to do that and have to call IT?” look and walked away shaking my head. No one in his/her right mind would purposely “interface” with IT unnecessarily.

monitorAs luck would have it, I found myself working in IT a year later. On my first day, I had to sign on and predictably, the system crashed within an hour.  I became the network operations’ comic relief when they asked me my terminal address and I responded that I was on the eighth floor. Over muffled laughter, they told me they needed the 16-digit number on the side of my terminal (monitor)… and added that they were also on the 8th floor.

I had no idea that my English fluency would be so tested in IT.  While I knew that English is the language that separates so many across countries, I didn’t know it also was true with IT.

What is the solution for IT English?

misunderstandIf we truly want to make progress with technology, we need to recognize the walls that IT English puts up around us.  It’s not enough to know that there are walls and to converse with each other – we need to care about the misunderstanding that arises whenever we redefine English words and expect the world to understand.

IT needs to stop talking in acronyms and start translating our IT  English into English English or American English (a dictionary or savvy translator can help) so that when we talk technology, others will listen.

That is, if we truly want to communicate with the business.  It reminds menapoleon of the English Channel Tunnel (Chunnel) project:  did you know that it was originally started by Napoleon over a hundred years earlier?  The project stopped when Napoleon realized that the tunnel would not be a one-way deal…

What do you think? Am I being too cynical about IT?  Is there hope for IT English to become mainstream or vice versa?

(Fade to black with the strains of Dr. Doolittle’s “I want to talk to the animals…” )

Have a productive week!


P.s. Don’t forget to register for the #LSSC11 FREE Webinar series – Feb. 2, 2011 (noon-1pm PST — 3 -4pm EST!)  Session #1: INTRODUCTION TO KANBAN with Janice Linden-Reed. Register here:


IT's all about the People, Stupid...

(Note to self: Remember Mark Twain’s quote – If I had more time, I’d have written less…)

It seems apropos to use this headline to illustrate soft skills’ importance in software development (the 1992 Clinton presidential campaign coined the originalIt’s the economy, stupid).

What do you think?  Do technology skills trump people skills in IT (this was the traditional engineering approach)?  I believe that people skills are at least as important – if not more important – than the hard methodology or coding skills.

I believe that the lack of people skills are at the root of several issues in IT today, unless you work on projects for unknown customers, such as the story this week in the NY Times: Can Apple Find More Hits without its Tastemaker:

Steve JobsShortly before the iPad tablet went on sale last year, Steven P. Jobs showed off Apple’s latest creation to a small group of journalists. One asked what consumer and market research Apple had done to guide the development of the new product.

None,” Mr. Jobs replied. “It isn’t the consumers’ job to know what they want.”

“IT would be easier without the people”

One of my first MIS projects as a programmer was memorable for two reasons:

  1. It was the first time I heard the phrase above; and
  2. My boss made a deal to get sponsor sign-off on requirements by promising that he (the sponsor) could change anything down the road that he didn’t understand.

It was a project from hell (change running rampant) and it was the first time I truly realized that we go into computer science and engineering because we are good at technical subjects, not communication.  Back then, waterfall development was essentially done “over the fence” with the business throwing the requirements over to us, we doing the design and build, and then us throwing the finished software back to the business for testing. More often than not, our “perfect” software missed the mark in terms of functionality, and was typically late and over budget.

Certainly much has changed with the new approaches – can you imagine software development without regular end-user contact?

How much rework is people-based?

CalendarDoes it surprise you to learn that software development is fraught with rework – in traditional settings it is close to 40%?  This means – literally – that we do great work every Monday, Tuesday and Wednesday, and then get to redo it all every Thursday and Friday.

Thanks to Kanban, Agile, Lean, Scrum and other customer-focused methods, our industry is getting a lot better at reducing rework, and at identifying non-productive wait times/delays from customers and others. We are also better at knowing how to deliver incrementally to customer needs. Augmenting the new approaches are job roles specifically tasked with customer facing such as business analysts, project managers and user advocates or scope managers. Some might argue that these roles are inconsistent (or even counterproductive) with Lean or Agile approaches, but that is the topic of a future post.

Regardless of approach, however, engineers and computer scientists are no fundamentally different today than they were in the days when I attended college.  We choose these professions because we love math, science and technology, have a reasonably high-IQ, and want to make a difference in the future of the world (at least that is my excuse!)  People do not go into engineering or computer science for the people skills.

Sure, there is a growing recognition that both engineers and computer scientists must have good people skills when they enter the workforce, however, soft skills training is still secondary.  Soft skills remain some of the most elusive and necessary skills in software and systems development.

(Side note: at an SEPG conference several years ago, research showed a high concentration of early onset autism/Asberger’s syndrome among Silicon Valley’s professionals.  For SEPG, this was a very controversial session that led t interesting results: 1. developers who already felt socially inept wondered just how inept they might be; and 2. others took careful notes so that they could report people they didn’t get along with to HR with the suspicion that they might be autistic. Presenters were careful to say that this research was inconclusive and PRELIMINARY.)

In my experience software engineers score high marks in technical areas but fall short in communication skills because:

  • they do not realize that they are poor communicators (their co-workers and friends understand them);
  • they see themselves as superior in intelligence to non-IT’ers, which can lead to condescending behavior (“what do you mean that you don’t know what these acronyms mean?”
  • they do not realize that both the sender and receiver are part of the communication loop (as in “I understand perfectly, it’s the business who has a problem”);
  • they value technical proficiency over soft skills proficiency (if something is not complex and technical, where is the value?); and
  • they have not taken soft skills training aside from a presentation skills course in college.

What did I miss on this list?

What are soft skills?

While I hate to quote Wikipedia, it has a good definition for soft skills (better than

Soft skills is a sociological term relating to a person’s “EQ” (Emotional Intelligence Quotient), the cluster of personality traits, social graces, communication, language, personal habits, friendliness, and optimism that characterize relationships with other people. Soft skills complement hard skills (part of a person’s IQ), which are the occupational requirements of a job and many other activities.

Soft Skills are behavioral competencies. Also known as Interpersonal Skills, or people skills, they include proficiencies such as communication skills, conflict resolution and negotiation, personal effectiveness, creative problem solving, strategic thinking, team building, influencing skills and selling skills, to name a few.

How many of these skills are explicitly taught as part of Scrum, Kanban, Lean or Agile training?  (In fairness, they were never taught in waterfall or structured analysis classes.) I know that there is at least recognition of soft skills importance with newer customer-centric methods, and I believe there is still a gap.

Are you better at presenting and communicating with users doing  Kanban or Scrum than you would be if you were involved in waterfall development?

As our industry has learned better ways of developing software-intensivScalee systems, neither our business partners nor we are well skilled in soft skills.  Accountants, marketing majors, doctors, actuaries, and human resources can also suffer from too much IQ and not enough EQ.  So, who is responsible for making sure that business outcomes, funding levels, and trust are present in the IT/Business partnership?  Both sides are definitely responsible for their own part to make things better.

On the development side, we need to recognize that prowess in terms of effective communication, knowledge transfer, people networking, facilitation, cultural awareness, etc. do not come by osmosis – we need soft skills practice and training.  When we are experts at both the hard and soft skills, our entire industry will gain – and so will our business partners.

How are your soft skills?  Here is a quick quiz:

Soft skills workshops?

It is easy to blame misunderstanding, lack of technical prowess, and poor communication on users, but IT has yet to recognize that IT’s not about the business; IT is all about the people.

Are you interested in attending a dedicated session on soft skills for technical professionals?  Drop me an email for information on my upcoming one-day IT’s all about the People workshop.

Have a productive week!



WTP?* No more methodology battles...

Ever since my college days (many months ago!) there has been a “situation” concerning IT and the business.  Despite a plethora of new methods, technologies, software, and business-focused efforts, the valley of communication between IT and the business remains. Sure, there has been progress – business analysts, project management, agile development, Kanban and others have brought the customer to the table (so to speak) with software developers, but the gap remains.

Just today, a colleague in the Kanban / Lean development space remarked on Twitter:

Master servant“I think IT and business are stuck in a master / servant relationship as opposed to a trusted partner one.”

It seems that the more that things change, the more they stay the same… and it is frustrating. There is so much work to do in terms of communication, education, soft skills to bridge this gap.

So WTP* of methodology battles?

Really, WTP (What’s The Point) of methodology battles in software development? I see it all the time in cyberspace and at conferences:

  • Function points (and flavors within) versus lines-of-code versus story points versus use case points;
  • CMMI® versus SPICE (a European framework);
  • PMI (Project Management Institute) certification versus IPMA (International Project Management Association) versus Prince 2;
  • Kanban versus Agile versus Scrum versus Waterfall?

Perhaps it is human nature to pick battles we think we can win (as opposed to looking at the overall bigger challenge of the business / IT dysfunction), but What’s the Point?

When you come down to it, a Win/Lose result in software development (along the lines of schoolyard “My mother is smarter than your mother”) ends up being a Lose/Lose for everyone involved. Emotions flare, tempers rise, and time is wasted.  In addition, when you consider the bystanders (other professionals and executives) watching these methodology “catfights”, it’s no wonder many of them step back and retrench without a second thought about ways forward.

Case in point – the function point wars fueled by assertions of “my way (of counting) is better than yours” or “ours is a 2nd generation method while yours sucks” is a pitiful battle proposition when one considers that a mere 10% of organizations measure any software development at all.  Yet the battles go on fueled by notions of superiority and self-congratulation.  (It is no wonder why some organizations forego function points altogether.)

I see the same battles brewing in the Kanban, Lean, Agile, RAD and Waterfall communities.  While each approach offers its own advantages and strong points, none is a panacea and in fact, a diversified team of qualified practitioners can often blend practices to increase output and quality.  When allowed to co-exist in relative harmony (with the goal to deliver better software, reduce rework, and delight customers) – the results could be stellar.  But, we’re not there yet.   I can imagine that when the power nailgun was introduced into construction, it probably faced the same resistance as modern methods have in software development.  Of course, since human beings and professional credibility is involved in both industries – opinions emerge about the best way forward.

No matter which “camp” or area you adhere to in software development, there is no silver bullet or Swiss Army Knife.  We have to learn to lay down our petty differences and work together for the betterment of our customers – and over time, maybe our customers will take notice that we are collaborating for them.

LSSC11If you agree with the notion of collaborating and learning about how professionals are integrating these various approaches (and others) together, be sure to attend LSSC11 (sponsored by the Lean Software and Systems Consortium) being held May 3-6, 2011 in Long Beach, CA.

I can promise you’ll see Kanbaners, Agilistas, Scrumbies, Sigmalites, and even a few Waterfallers working the space networking, sharing, and gently sparring (in jest) – all for the advancement of our industry.  Why not plan to join us?



northernSCOPE™ – A customer-facing project measurement and accounting system for Lean, Kanban, Agile, etc.

I’m going to start this post off in a non-traditional way with the p.s., first:

p.s., Don’t forget to register for David Anderson’s free webinar coming up on January 18, 2011.  Listen to the “Father of Kanban” discuss Lean Decision Making
from 12-1pm PST (3-4 pm EST)

– it’s free knowledge sharing by one of our industry’s best minds today!  Register here.

How to report project progress for Kanban, Lean, Agile, and other projects?

It remains a challenge to deliver appropriate business-focused reports to executives during software projects.  For decades, the IT industry grappled with ways to streamline and ease translation of technology into business terms, but today we have promise with new approaches.   There is no question that Kanban, Lean, Agile, XP, Scrum, and other approaches bridge the customer developer gap, and bring the customer in direct contact with development teams.  These and other methods increase mutual understanding, facilitate communication and enhance overall software delivery.

In addition, methods such as the Capability Maturity Model Integration (CMMI®) and Balridge Quality criteria complement these as well as traditional software development approaches through standardized best-practice processes.

Executives accustomed to numerical results, however, remain challenged at the lack of standardized business oriented metrics for reporting project progress and assessing outcomes.  How can one prove that Kanban, Agile, XP, Lean, or even CMMI® deliver software to meet the needs as well as (or better than) traditional approaches?  How can we prove that functionality delivered today meets or exceeds what is required or replaced?  Where are the business gauges to help executives chart progress towards program or project goals?


One promising method for measuring project progress independently of the work methods is  called northernSCOPE™ and it can work seamlessly alongside of software development to report progress in business terms using metrics suitable for the type of project work. Just as a home buyer needs to know that the finished product meets his/her needs and was delivered at a fair overall cost, so too do executives need bottom-line oriented reporting about the progress and delivery of software.

While northernSCOPE™ was developed and first worked along with traditional software development such as waterfall and spiral, it is easily adapted to work with iterative approaches as well.  The beauty of northernSCOPE™ is that the business can follow along with software development from a functional, business perspective and can track investment by type of work (functional software delivery versus modification versus porting, etc.). What is different about northernSCOPE™ versus traditional measurement reporting is that a “program” or “project” of work is first divided into sub-projects each of which can be accounted for with applicable metrics.

I use a construction analogy to explain northernSCOPE™:  If I need to have a house built somewhere along the east coast of the United States, large enough to hold my burgeoning family (2-3 children), a fully landscaped yard, a pool (if the weather permits), and potentially a guest house, how would a builder estimate and cost out this project for me?  Without knowing what I want and need at this point early in the project (I may not even know what I mean when I say a “house”), a wise builder will subdivide the project into various parts, at least with:

1.      Site selection, purchase, and preparation.  This would include research of available sites, pricing, purchase, and clearing of the land in anticipation of construction (similar to initiation of a project in software project management) – a standalone project paid for likely by hours expended plus the cost of the building site and permits.

2.      Home design and construction, which could be done in many ways from building one room at a time modularized (akin to agile software development) or a floor at a time (more waterfall or spiral like).  Pricing by the square foot would be a good way to manage and report on the progress of this separate project.

3.      Landscaping.  Again, a separate piece of work that would be done completely differently than #1 or #2 above.  Progress would be reported on a percentage complete, number of pallets of sod laid, or number of trees planted, and payment would be made on the same basis.

4.      Guesthouse design and construction.  This would again be a separate piece of work, which would resemble #2 in terms of progress and payment.

5.      Other work (such as furnishing the home). This would be a separate project requiring different tasks and labor and may be done incrementally room by room as progress on #2 is done.  Progress and payment would likely be done based on types and quality of furniture or appliances acquired.

6.      At the end of the project, the homeowner would pay for the work done (and changes would be managed with change orders whose cost would be based on unit pricing according to the work type) as agreed to during the projects.  Note that changes in the choice of trees would not affect the house construction price, and changes in the site selection process would not affect the landscape unit costs.  By unit pricing and measuring each sub-project separately, the homeowner never loses touch with or confidence in the overall project. In addition, the overall construction manager (the general contractor) can continue to work on the various parts of the project without interruption.  He/she will be paid for all the work done on behalf of the homeowner (with their agreement) so there is also flexibility built into the arrangement.

This is similar to how northernSCOPE™ works in software development.  At the beginning of the program or project, work is allocated into categories – software development (which is delivered through releases, scrums, iterations, etc), operations, enhancement, hardware installation, migrating of data, etc.  Each category or sub-project is then assessed in terms of unit pricing (for software delivery $ per function point can be used, for operations $ per hour can be used, etc) and the project commences.  When work in a Kanban environment is done, northernSCOPE™ would divide such work into a category and tracks its progress through to its delivery based on the right units.  Iterative and agile approaches would deliver functionality bit by bit, with progress reported according to functions and features delivered. The beauty of northernSCOPE™ is that it works to envelope what is being done on the project regardless of whether it is being delivered using Kanban, Agile, or other methods, and provides a business oriented view of the project to executives.

We have come a long way in software intensive systems development with the emergence of Kanban, Lean, Agile, XP, CMMI®, PSP/TSP and other advancements.  To bridge the gap with executives and close the circle (so to speak) with the business, northernSCOPE™ offers a solution – it affords one a way to measure and account for project progress independently of the underlying process(es).

Want to know more about northernSCOPE™?  Visit for related articles (or send me an email) or view prior posts on the subject.  In addition, there are northernSCOPE™ workshops I am planning for US locations in 2011.  Let me know if you would like to know more.

To your productive #Lean, #Kanban, and #Agile projects!



There's no time for "One of these days is none of these days" in IT

Let’s face it

– an investment in software development can be one of the most expensive and medieval timesrisk-laden endeavors a corporation can make, especially when requirements volatility and uncertainty are part of the mix.  In medieval times (of software development this would be pre-2000), customers and developers often jostled over requirements and clashed on issues of flexibility during strict waterfall development.  Then after months of protracted requirements discovery, the construction process would be frequently disrupted by “unanticipated change”.

Fortunately, for everyone involved, innovative techniques flexible to change and offering shorter, more iterative delivery cycles emerged.  Today, a myriad of choices exist that embrace flexibility and deliver high-quality software more effectively and efficiently than ever thanks to agile, XP, scrum, CMMI, project management and other concepts.  Additionally, methods that worked well in other industries have been adapted and tailored for use in IT (six sigma, kaizen, TQM, theory of constraints, just-in-time, Kanban, etc.).

A few of the most fundamental

yet simple concepts of Lean/Kanban/Just-in-Time development (and other methods) include minimizing waste (non-value added activities), removing roadblocks/delays and limiting work-in-progress (WIP).

If we consider software development as a “pipeline” of constant flowing work packets, any unresolved blockages can end up clogging the entire system.  As such, when life intervenes (as it always does) to interrupt or delay the flow of a work packet, approaches such as Kanban  highlight potential blockages before they clog the entire flow.  Teams can then identify remedial actions so that the right work is done at the right time, freeing up resources to concentrate on work where they can be highly productive.  Moreover, while waterfall development commonly fills the pipeline beyond capacity (without realizing it), Kanban limits the input stream to match the available capacity.  Once work is actively in the pipe, a critical delay (“one of these days…”) signals trouble and work can be removed (“none of these days”) until such time as it can be productively worked again or triaged to prevent ongoing delays.  If we are serious about reducing waste (non-value added activity) or delays, IT should never tolerate proverbial “one of these days is none of these days” delays in process.

Unexpected events and delays are a natural part of life (and software development).  The difference with Kanban and JIT is that there is a conscious response to bottlenecks and work stoppage rather than panic or blame reactions (OMG!  What do we do now?) typical of waterfall development.

Can Kanban co-exist with Agile development?

I believe so (and perhaps this is the attitude of a naive believer in both).  Can Kanban co-exist with Waterfall development? Again, I believe the answer is yes.  What do you think?

Don’t forget to register (and tell your management to register!) for the upcoming FREE knowledge webinar on January 18, 2011 featuring

LSSC11 Chairperson, Kanban expert and Author:
David Anderson

on Lean Decision Making, January 18, 2011 from noon – 1 pm Pacific Standard Time (3-4pm Eastern Standard Time). Here’s what this FREE webinar is all about:

Lean thinking assumes it is economically better to build a culture of trust in an organization of empowered individuals to accelerate decision-making and shorten lead times than to mitigate risk with bureaucracy and delayed delivery. Understand the economic model controlling the forces of risk, uncertainty, business value, quality, cost and schedule that affect decision-making and process policy setting. This webinar will show how lean thinking can translate into process and policy decisions more closely aligned with business goals.

Register today to reserve your webinar place!

Why not make 2011 the year that you make a difference in the world of software development by getting up to speed on Lean approaches?  Plan to join us 3-6 May 2011 in Long Beach, CA, USA for the Lean Software and Systems conference (acronym LSSC11) – register today!


Jeopardy for IT projects... the answer is July 15

JeopardyIn the popular television game show Jeopardy, contestants are given short phrase answers and are challenged to pose the associated question.  The half-hour show has been a mainstay on prime time television for many years and boasts millions of viewers.

While Jeopardy provides great no-risk entertainment for contestants and viewers, a real-life “game” of Jeopardy plays out daily in corporations throughout the world, only it’s called something else: Date-driven-estimating!

Here’s how it typically plays out:
Business executive:  “July 15.”  (The Jeopardy style answer)
Contestant / CIO (pondering): “Is that the date you announced that the software would be ready?”
Business executive:  “Correct!  Now make it happen.”

Poor project estimating is one of the pervasive issues in software development – and the situation doesn’t seem to be getting any better despite process improvement models such as the Capability Maturity Model Integration (CMMI(R)) and formal project management.

It doesn’t seem to matter how advanced or mature is the IT organization – good project estimation is elusive.  When a project does come in according to schedule, it is often a matter of coercion – that is the project manager has cajoled, manipulated or somehow morphed the project schedule to match an often arbitrary end date.

Author Steve McConnell once coined the phrase “Date-Driven-Estimating” and stated that it was the most prevalent estimating method in use today.  In Date driven estimating, management announces the project delivery date and then the project team works backwards to the current date.  The worst-case (and not unlikely) result is when the project can make the date ONLY if it was started several months ago.  The schedule is then retrofitted by piling on more resources along the timeline until everything is included between the start and end dates.  Somehow, such artificial manipulation transforms the impossible schedule into one that can work…

In engineering projects where physical and scientific constraints are fixed (such as the days required for concrete to cure), it is easier to see that such practices are prone to create outright project failures before the project even gets started.  For example, a road construction project cannot be sped up by adding too many resources – physical limitations of engineering construction prevail and building codes govern project progress.  Not so in software development.  In fact, just this evening I met someone from a major financial services company who told me of a software project where the coding commenced within two weeks of the project start – even before they had documented the requirements.  (No, it was not an agile project!)

What can be done when there is a pre-set budget or firm schedule set before any requirements are documented?  From an investment point of view, customers want to curtail costs during the development and still get the software they need to improve their business.

From a supplier point of view, the goal is to get paid for the hours expended delivering the correct solution while being flexible to the inevitable changes that will happen along the way.

The two approaches seem at odds with one another – customers want to be fiscally responsible for curtailing costs, and suppliers want to be responsive to their customers yet get paid for the work they are directed to do.  Firm fixed price projects (even before requirements are known) have been the solution preferred by customers to minimize the risk of budget overruns but all the risk is assumed by the supplier – especially before requirements are known.  But as in any partnership there is no such thing as a win/lose partnership – if the customer wins and the supplier loses – both sides ultimately lose.

So, what can be done to avoid such a dilemma and achieve a win/win scenario?  One solution is to deliver bite sized, incremental 2-week software releases using Agile Methods (scrums) .  A two-week timeframe is easier to manage and gain an accurate estimate than is a long-term development project.

Another approach is unit pricing…. Unit pricing is based on working with a cost per function point (software sizing) and is a promising and realistic option to reach success.  This approach plus other evolutionary steps are contained in the northernSCOPE model – already successful in Finland, Australia, and other countries.

Watch this space for more about the northernSCOPE approach and upcoming US training workshops.

Meanwhile here’s a couple of earlier posts on the topics:

Isn’t it time we changed the channel and stopped playing IT Jeopardy?



EU nations receptive to Scope Management

Greetings from Copenhagen

Bo Balstrop, Carol Dekkers, Morten Korsaa
Bo Balstrop, Carol Dekkers, Morten Korsaa

I have to confess that Europeans are much more progressive and receptive to evolutionary ideas such as northernSCOPE and formalized unit pricing ($/FP) on public tendering of IT projects than the U.S.  Just this week, I met with four different groups and presented the highlights and gains to be made from adopting formalized scope management, and I am hopeful that we (Delta Axiom of Denmark, my company Quality Plus Technologies, and 4SUM Partners of Finland) can begin to offer Certified Scope Management (CSM) training courses in Denmark in the not-too-distant future.  The approach is straight-forward and minimizes the lose/lose risk that accompanies firm fixed pricing of software projects when the requirements are not well-known.

Also interesting was the fact that those most interested in learning more about the method are not even from customer or developer groups that outsource (tender) their software development, but rather companies that do development in-house.  It wasn’t a hard sell at all – the audiences in all four presentations were receptive, open to discuss how northernSCOPE might work in their organizations, and optimistic about how it can succeed in Denmark.  After all, if we can create the demand for Certified Scope Manager (CSM) services with the public or private sectors, then training is the natural next step to create CSM’s to satisfy such demand.

Representatives from one of the nation’s largest government departments that governs taxation, the equivalent of the IRS in the US, were on-hand and expressed interest in knowing more.  I’m not sure why, aside from the “not-invented-here” characteristic (that plagues more than just the US), scope management has not raised anything more than a passing glance in the US.  With all the major expenditures on software intensive systems projects underway with our public administration and Department of Defense, together with rework figures hovering around 40%, you’d think that formalized Scope Management (aka northernSCOPE) would be of interest.  While the economy definitely plays a role to cut interest in training and consulting overall, it is still a question mark in this author’s mind why there is little interest despite ample presentations and workshops I’ve done at technology conferences throughout the US over the past few years.

No worries though… as long as some part of the world sees value in the method today – it matters not where the demand is rising.  It will be interesting to watch as more CSM’s are certified in Europe to see if it peaks any interest in my home continent.

Best wishes for healthy, productive projects.

p.s., Want to know more about northernSCOPE and the Certified Scope Manager (CSM) designation?  Email me for a copy of our northernSCOPE brochure and our CSM training information.



Ever had this problem in Software Development?

software development videoHave you ever felt that the business side of software development just doesn’t understand what’s involved?  Watch the short video I created (just click on the “photo” above) and let me know if this is anything like what you’ve ever experienced.

It’s no wonder that so many projects end up over budget, behind schedule and delivering a product that just doesn’t fit.  One solution is scope management.  Call or email me today for a free white paper about Scope Management (

I know the video is tongue-in-cheek but I’d like to hear your comments!

Have a good day,

Defining IT Project Success

When the annual Standish Group Chaos report is published, IT professionals wait to hear whether the “project success rate” has gone up or down.  Between 1996 (the first year of the Chaos report) and 2006, the success rate doubled from a low of 17% in 1996 to a high of 34% in 2006.  Since then the rate has deviated up or down by a couple of percentage points.

In the Chaos reports, project success is determined to be on-time, on-budget, and delivering to requirements.  I don’t agree that this is a good assessment of project success, what about you?

[polldaddy poll=4093887]