12 Common Mistakes in Project Management By Cora Systems Some organization’s projects have been unduly criticized for being poorly planned and managed and having unrealistic cost and time projections assigned to them. The reason behind these problems or mistakes is said to be down to a lack of communication through the different levels within the project management [...]

As an industry we do a surprisingly poor job of measuring the work that we do and how well we do it. Outside of a relatively small number of organizations which bought into expensive heavyweight models like CMMI or TSP/PSP (which is all about measuring on a micro-level) or Six Sigma, most of us don’t measure enough, don't measure the right things or understand what to do with the things that we do measure. We can’t agree on something as basic as how to measure programmer productivity or even on consistent measures of system size –should we count lines of code (LOC, SLOC, NCLOC, ELOC) or IFPUG function points or object oriented function points or weighted micro function points or COSMIC Full Function Points, or the number of classes or number of something else…?

Capers Jones, who has spent most of his career trying to understand the data that we do collect, has this to say: The software industry lacks standard metric and measurement practices. Almost every software metric has multiple definitions and ambiguous counting rules… The result of metrics problems is a lack of solid empirical data on software costs, effort, schedules, quality, and other tangible matters. Strengths and Weaknesses of Software Metrics, 2006

But how can we get better, or know that we need to get better, or know if we are getting better, if we can’t or don’t measure something? How can we tell if a new approach is helping, or make a business case for more people or a rewrite, or even justify our existing costs in hard times, without proof?

What do you really have to measure?

Different metrics matter to management, the team and the customer. There are metrics that you have to track because of governance or compliance requirements, or because somebody more important than you said so. There are metrics that the team wants to track because they find them useful and want to share. There are stealth metrics that as a manager you would like to track quietly because you think they will give you better insight into the team’s performance and identify problems, but you aren’t sure yet or you don’t want people to adapt and try to game what you are measuring. And most important, the measures that the customer actually cares about: are you delivering what they need when they need it, is the software reliable and usable?

Like most people who manage development shops, it’s much more important to me to get work done than to collect measurement data. Any data must be easy and cheap to collect and simple to use and understand. If it takes too much work, people won’t be able to keep it up over the long term – they’ll take shortcuts or just stop doing it. The best metrics are the ones that come for free, as part of the work that we are already doing. http://www.amazon.com/Managing-Design-Factory-Donald-Reinertsen/dp/0684839911 I need a small number of metrics that can do double duty, that can be combined and used in different ways.

Size

In order to compare data over time or between systems and teams, you need a consistent measure of the size of the system, the size of the code base and how this is changing.Counting the Lines of Code, whether it is Source Lines of Code (SLOC)or Effective Lines of Code (ELOC) or NCLOC (Non Commented Lines of Code), is simple and cheap to measure for a code base and easy to understand (as long as you have a consistent way of dealing with blank lines and other formatting issues), but you can’t use it to compare code written in different languages and on different platforms.

This is where Function Points come in – a way of standardizing measurements of work for estimation and costing independent of the platform. Unfortunately it’s not easy to understand or measure Function Points – while there are lots of tools that can measure the number of lines of code in a code base and every programmer can see and understand what 100 or 1000 lines of code in a certain language looks like, Function Point calculations need to be done by people who are certified Function Point counters (I’m not kidding), using different techniques depending on which of the 20 different Function Point measurement methods they choose to follow.

Function Points have been around since the late 1970s but this way of measuring hasn’t caught on widely because it isn’t practical – too many programmers and managers don’t understand it and aren’t convinced it is worth the work. See “Function Points are Fantasy Points”.

A rough compromise is to use “backfiring” rules-of-thumb to convert from LOC in each language to Function Points (you’ll need to find a good backfiring conversion table). With backfiring, 1 Function Point is approximately 55 lines of Java (on average), or 58 lines of C#, or 148 lines of C. There are a lot of concerns about creeping inaccuracies using this approach, but for rough comparisons of size between systems in different languages it’s all that we really have for now.

Where are you spending time and money, and are you doing this responsibly?

Everybody has to track at least some basic cost data – its part of running any project or business. What’s interesting is coming up with useful breakdowns of cost data. You want to know how much people are spending on new stuff, on enhancements and other changes, on bug fixing and other rework, on support, on large-scale testing work, on learning – and how much time is being wasted. Whatever buckets you come up with should be coarse-grained – you don’t need detailed, expensive time tracking and other cost data to make management decisions. If everyone is tracking time for billing purposes or project costing or OPEX/CAPEX financial reporting or some other reason it’s easy. Otherwise, it’s probably enough to take samples; ask everyone to track time for a while, work with this data, then track time again for a while to see what changes. With a common definition of size across systems (see above), you can compare costs across teams and systems, as well as look at trends over time.

For maintenance teams, Capers Jones recommends that teams track Assignment Scope: the amount of code that one programmer can maintain and support in a year. You can use this for planning purposes (how many people will you need to maintain a system), watch this change over time and compare between teams and systems (based on size again), or even against industry benchmarks. According to Capers Jones’s data, an average programmer should be able to maintain and support around 1,000 Function Points of code per year, depending on the programmer’s experience, the language, quality of code and tools.

Speed

Everybody wants software delivered as fast as possible. Agile teams measure Velocity to see how fast they are delivering at any point in time, but the problem with velocity, as Mike Cohn and others have explained in detail, is that it can’t be compared across teams, or even within the same team over a long period of time, because the definition of how much is being delivered, in Story Points, isn’t stable or standardized – Story Points mean different things to different teams, and even different things for the same team over a long enough period of time (as people enter and leave the team and as they work on different kinds of problems). Velocity is only useful as a short-term/medium-term predictor of one team’s delivery speed.

Teams that are continuously delivering to production can measure speed by the number of changes they are making, and the how big the changes are (we’re back to measuring size again). Etsy measures the frequency of changes and the size of the change sets, and correlates this with production incident data (frequency and impact and time to recover) to help understand whether they are changing too much or too quickly to be safe.

Probably the most useful measure of speed comes from Lean and Kanban. To determine if you are keeping up with customer demand, measure the turnaround or cycle time on important changes and fixes: how long it takes from when the customer finds a problem or asks for a change to when they get what they asked for. Turnaround is simple to measure and obvious to the business and to the team, especially if you use something like Cumulative Flow Diagrams to make cycle time visible. It’s easy to see if you are keeping up or falling behind, if you are speeding up or slowing down. Focusing on turnaround ties you directly to what is important to the business and your customers.

Reliability and Quality

But speed isn’t everything – there’s no point in delivering as fast as possible if what you are delivering is crap. You also need some basic measures of quality and reliability.

For online businesses, Uptime is the most common and most useful measurement of reliability: measuring the number of operational problems, the time between operational failures (MTTF), and the time to recover from each failure (MTTR). Basic Ops stuff.

And you need some kind of defect data, which come free if you are using a bug tracking system like Bugzilla or Jira. Identify areas in the code that have the most bugs, measure how long it takes to fix bugs and how many bugs the team can fix each month. Over the longer term, track the bug opened/closed ratio to see if there are more bugs being found than normal, if the team is falling behind on fixing bugs, if they need to slow down and review and fix code rather than attempting to deliver features that aren’t actually ready.

To compare between teams or systems or to watch trends develop over time, one of the key metrics is defect density: the number of bugs per KLOC (or whatever measure of code size you are using – back to the size measurement again). With enough data, you can even try to use defect density to help determine when code is really ready to be shipped.

How Healthy is the Code?

You also want to measure the health of the code base, how much technical debt you are taking on, using code analysis tools. Code coverage is a useful place to start, especially if you are putting in automated testing, or even if you just want to measure the effectiveness of your manual testing. Tools like EMMA and Clover instrument the code and trace execution as you are testing to give you a picture of what code was covered by testing, and more important, what code wasn’t. It’s easy to drill down and see where the holes in your testing are, and to build trends from this data, to set code coverage targets and watch out for people cutting back on testing under pressure.

Measuring Code Complexity, identifying your most complex code and watching to see if complexity is increasing over time helps you make decisions about where to focus your reviews and testing and refactoring work. If you are measuring both test coverage and complexity, you can correlate the data together to identify high risk code: complex routines that are poorly tested. Code health can also be measured by static analysis checkers like Findbugs and PMD or Coverity or Klocwork – tools that look for coding mistakes and security vulnerabilities and violations of good coding practices. Higher-level code quality management tools like Sonar and CodeExcellence, which consolidate and correlate data from multiple static analysis tools, give you an overall summary picture of the health of all of your code, and let you look at code health over time and across teams and systems.

Using Metrics in Ways that aren’t Evil

Many programmers think that metrics are useless or evil, especially if they are used by management to evaluate and compare programmer productivity. IBM for example, apparently uses static measurement data to scorecard application developers and teams and in an attempt to quantify programmer performance. Using this kind of data to rate developers for HR purposes can easily lead to abuse and reinforcing of the wrong behavior. If you are measuring “productivity” by size and simple code quality measures, no programmers will want to take on hard problems or step up to maintain gnarly legacy code because their scores will always look bad. Writing lots of simple code to make a tool happy doesn’t make someone a better programmer.

Only measure things to identify potential problems and negative trends, strong points and weak points in the code and your development process. If you want to set goals for the team to improve speed or cost of quality, let them decide what to measure and how to do it. And measure whatever you need to build a business case – to prove to others that the team is moving forward and doing a good job, or to make a case for change. Make metrics work for the team. You can do all of this without adding much to the cost of development, and without being evil.

Convincing Functional Managers To Do Consistent Resource Planning By Kiron D. Bondale As with any other behavior change, convincing functional managers that it is a good idea for them to do their regular team planning in a centralized, consistent fashion can be a hard sell. There’s little doubt that there’s benefit to the senior management team of [...]

Note: I wrote this piece in 2009, intending to post it on Eight to Late. Around that time Paul Culmsee and I were just starting out on our book, The Heretic’s Guide to Best Practices. I was pretty sure this piece would find a place in the book so I held off from blogging it, and as it turned out, it ended up in Chapter 4 which is entitled, Managing Innovation: The Demise of Command and Control.  A few days ago, I stumbled on the original piece in my draft archives.  I thought it stands quite well on its own, so here it is…

Introduction

The dictionary defines the word innovation as:

Innovation (n):  something new or different introduced

This definition leaves the door wide open as to what the term means: an innovation could be a novel product to blow the competition away to a new way to organise paperwork that makes it easier to find the hardcopy of the contract you’re after.

Organisations hunt high and low for the magic formula that would enable them to foster and manage innovation. So management gurus, consultants and academics oblige by waxing at length on the best way to inspire and direct innovation (there has to be a process for it, right?). And there’s the paradox:  the more we chase it, the further it seems to recede. But that does not stop organisations from chasing the mirage. In this post I present a few reflections on creativity and innovation based on a couple of personal experiences.

The first story

In the early 90s I started working towards a research degree in chemical engineering at   University of Queensland. Given my theoretical leanings, I naturally gravitated towards the mathematically-oriented field of  fluid dynamics. I’d spoken to a couple of folks working in the area, and finally decided to work with Tony Howes, not only because I found his work interesting, but also thought that his quick intelligence and easygoing manner would make for a good work environment.

I spent a few weeks – or was it months – trying to define a decent research problem, but got nowhere. Tony, sensing that it was time to nudge me towards a decision, suggested a couple of problems relating to a phenomenon that is easily demonstrated in a kitchen sink. If you’re game you may want to make your way to the nearest sink and try the following:

Turn the tap on slowly until water starts to flow out as a cylindrical jet. You will notice that the jet breaks up into near spherical droplets a short distance from the mouth of the tap.

This phenomenon is called jet breakup. Instead of describing it further, I’ll follow the advice that a picture is worth several words (see figure 1).

Figure 1: A water jet breaking up

If you are interested in knowing why fluid jets tend to break up into drops,  please see the next paragraph; if not, feels free to skip the bracketed section as it is not essential to the story.

[Boring details: The basic cause of break up is surface tension – which is essentially a force that keeps a fluid from becoming a gas. Surface tension arises from the unbalanced “pull” that molecules in the interior of a fluid exert on molecules on the surface. The imbalance occurs because molecules at the surface “feel” a pull only from the interior of the fluid. In contrast, molecules in the interior of the fluid are subjected to the same force on all sides as they are surrounded by fluid. One of the effects of surface tension is that fluid bodies tend to minimise their surface area. The upshot of this for cylindrically shaped jets (such as those emerging from a tap) is that they tend to pinch off into a series of drops because the combined surface area of the drops is less than that of the cylinder.]

To get back to my story:  I realised that I’d already burnt up a few months of a research grant so I agreed to work on one of the problems Tony suggested. Once I’d signed up to it, I hit the books and research journals getting up to speed with the problem. I learnt a lot. Among other things, I learnt that the problem of jet breakup was first studied by Lord Rayleigh in 1878! I also learnt that since the late 1960s, the phenomenon of jet break had enjoyed a bit of a renaissance due to applications such as inkjet printing. Tony had proposed a problem of interest to the metals industry – the production of shot from jets of molten metal. However, it seemed to me that this problem was at best a minor variation on a theme that had already been done to death.

Anyway, regardless of how I felt about it, I was being paid to do research, so I plugged away at it. In the process I developed a good sense for the physics behind the phenomenon, its applications and what had been done up until then. Although I wasn’t too fired up about it, I’d also started work on modelling the molten metal shot problem. It was progress of sorts, but of the dull, desultory kind.

Then one evening in October or November 1994, I had one of those magical Aha moments. …

I was washing up after dinner when I noticed a curious wave-like structure on the thin jet that emerged from the kitchen sink tap and fell onto a plate an inch or two below the tap (the dishes had piled up a while). The wave pattern was absolutely stationary and rather striking. Rather than attempt to describe it any further, I’ll just show you a a  photograph of the phenomenon taken by my colleague Anh Vu.

Figure 2: Stationary waves on a water jet.

The phenomenon is one that countless folks have noticed, and even I’d seen it before but never paid it much attention. Having been immersed in the theory of fluid jets for so long, I realised at once that the pattern had the same underlying cause as jet breakup. I wondered if any one had published any papers on it. Google Scholar and decent search engines weren’t available so I rushed off to the library find out.  A few hours of searching catalogues and references confirmed that I’d stumbled on to something that could see me through my degree and perhaps even give me a couple of papers.

The next day, I told Tony about it. He was just as excited about it as I was and was more than happy for me to switch topics. I worked feverishly on the problem and within a few months had a theory that related the wavelength of the waves to jet velocity and properties of the fluid.  The work was not a major innovation, but it was novel enough to get me my degree and a couple of papers.

This episode taught me a few things about innovation and creativity, which I list below:

1. Interesting opportunities lurk in unexpected places: A kitchen sink – who would have thought….
2. …but it takes work and training to recognise opportunities for what they are: If I hadn’t the background in the physics of fluid jets, I wouldn’t have seen the stationary waves for what they were.
3. A sense progress is important, even when things aren’t going well: Tony left me to my own devices initially, but then nudged me towards a productive direction when he saw I was going nowhere. This had the effect of giving me a sense of progress towards a goal (my degree), which kept my spirits up through a hard time.
4. It is best to work on things that interest you, not those that interest others: I stuck to my primary interest (mathematical modelling) rather than do something that was not of much interest but may have been a better career choice.

 The second story

Here’s another story, from a few years later when I was working as an applied mathematician within a polymer processing laboratory.

Some background first – polymer extrusion is an industrial process that is used to create plastic tubing from raw polymer pellets. It involves melting the raw material and driving the melt through a die with the required cross-sectional profile. A common problem encountered in this process is that at high flow rates, the melt emerging from the die has shark skin-like surface imperfections. This phenomenon is sometimes called the melt flow instability.

I was hired to work on a project to model the melt flow instability described above. I began, as researchers always do, by wading through a stack of research papers on the topic. Again this was a topic that had been over-researched in that many different groups had tried many different approaches. However none of them had answered the question definitively. I learnt a lot about modelling polymer flows (quite different from modelling flows of water-like fluids described in the earlier story) but didn’t make any progress on the problem.

Most of the other members in the research group were doing experimental projects, working in the lab doing stuff with real polymers, whilst I was engaged in modelling imaginary ones using simulations. Oddly enough, the folks engaged in the two strands of research did not meet much; I didn’t have much to do with them, and was happy working on my own little projects.

One day, after I’d been in the lab for a year or so, one of the experimentalists knocked on my door to have a chat regarding a problem he was having with a mathematical model he had developed. The reading and background work I had done up to that point enabled me to solve his problem rather quickly. Progress at last – but not in the way I’d imagined.

Encouraged by this, I started talking to others in the group and soon found that they had modelling problems that I could help with. I published a few papers through such collaborations and kept my academic score ticking along. More importantly, though, I got  – for the first time -  a taste  of collaborative work, and  I found that I really enjoyed it. One of the papers that we wrote rated a minor award, which would have helped my academic career had I stayed in the field. However, later that year I decided to switch careers and move to consulting. But that’s another story…

My stint in the polymer lab, very different from my solo research experience, taught me a few more things about creativity and innovation. These are:

1. Collaboration between diversely skilled individuals enhances creativity. It is important to interact with others, particularly professionals from other disciplines. I’m grateful to my colleagues from the lab  for drawing me out of my “comfort zone” of theoretical work.
2. Being part of a larger effort does not preclude creativity and innovation – although I did not do any experiments, I was able to develop models that explained some of the phenomena that my colleagues found.
3. Even modest contributions add value to the end product – great insights and epiphanies aren’t necessary – none of the modelling work that I did was particularly profound or new. It was all fairly routine stuff, done using existing methods and algorithms. Yet, my contributions to the research added a piece that was essential for completeness.

 Reflections and wrap-up

The events related above occurred in a research environment, but the lessons I took away have, I believe, a much wider applicability. Further, although the two stories are quite different – and hold different lessons – there are a few  common themes that run through them. These are:

1. When doing creative work, one invariably ends up with results that one didn’t intend or expect to find.
2. A shift in perspective may help in generating new ideas. Looking at things from someone else’s point of view might be just the spark you need.
3. Things rarely go according to plan, but it is important to keep ones spirits up.
4. Background is important; it is critical to learn/read as much as possible about the problem you’re attempting to solve.

The above conclusions hold a warning for those who night over-plan and control innovative or creative activities. In both cases I started out by defining what I intended to solve, but ended up solving something else. By the yardstick of a project plan, I failed. But by a more flexible measure, I did alright. By definition, the process of discovery is unpredictable and somewhat opportunistic – one has to be willing and able to redefine goals as one proceed, and at times even throw everything away and start from scratch.

Filed under: Management Tagged: Creativity, Innovation

I am lost. Or confused. Or at least something non-expert-like.

In September we have new elections in The Netherlands. Our current ruling parties cannot work together anymore.

I always vote. I think it’s important. As years go by I find it harder to choose which party to vote for. And we have a lot of them.

This time, I really have no clue.

This bothers me.

As I remember it, I used to have only a couple of choices. And the parties I could choose from represented a social group. Factory workers, small business owners, religious folks. If you’re a member of a certain social group, you’re choice is almost already made.

Both my grandparents were small business owners and I can trace my early voting behavior back to this.

Every party also had a single story for how things should be run: let the free market do it’s thing, tax the rich folks and redistribute wealth evenly, give priority to families. Stuff like that.

Easy choice. Easy solutions.

I love to map stuff. I like to know where I am in the political landscape.

Now I have many parties to choose from. Now I am not sure which social group they represent. I can only see a very small amount of flags.

Even within parties I am now confronted with internal elections broadcasted on television. Who will be the frontrunner for this party? So I get to see all the many faces from within a party. Increasing my options.

Media is providing me with information about every single candidate. Conflicting information of course.

There are no single stories any more. Or easy solutions that resonate with me.

Is this good or bad?

Yes.

Is this what Barry Schwarz meant with the Paradox of Choice? If you have too much options to choose from, you run into the risk of paralysis and being unhappy about your final choice, because you keep comparing them to the alternatives.

Perhaps.

It can also be a personal thing.

Perhaps when I started to vote there actually were many parties, but my vision of the landscape was limited.

Perhaps there are parties now with single stories, but I just don’t want to hear them. (blaming immigrants for example).

Perhaps I am not sure which social group I belong to.

I am glad I have the right to vote.

I am glad I have still 3 months to narrow my selection.

Lost. How To Choose Who To Vote For? is a post from: Project Shrink.

In this edition of “Where in the World is LiquidPlanner?,” we find ourselves in merry ol’ England! Blimey! (We don’t take any responsibility for the number of English slang words that make their way into this blog post, no matter how incorrectly they’re used).  

As of next week, a few members of the LiquidPlanner crew will be crossing the pond to attend the 2012 Social Workplace Conference. SWCONF focuses on the impact of social media and social software on internal communications and workforce collaborations. Now that sounds like our cup of tea.

At LiquidPlanner, we live and breathe collaboration, inside and outside of the office. We want you to be able to follow us every step of the way as we take on Londontown. Here’s a peak at our itinerary and how you can be a part of the big event:

The Conference

The Social Workplace Conference is going to be a blast. Here’s a little blurb from the conference website:

“#SWCONF will bring together Senior Executives to discuss the impact of Social Media in Workplace. The conference will also explore the growing applications of Social Software for Internal Communications & Workforce Collaborations.”

We’re excited to hear the talks, to meet new people, and of course, to EAT! But you know what the best part of the conference is going to be? Our very own Liz Pearce will be speaking about the ways Social Project Management can improve Enterprise Collaboration (a topic that we know quite a bit about). You won’t want to miss this! Make sure you say hello to her if you’re on location, or tweet her at @lizprc.

 

The Customer Meetup

We say this in every blog post, but I think it bears repeating: We love our customers. That’s why we’re putting on a happy hour just for our UK users. We know you Brits fancy a pint or two every now and again, and the next round is on us. Meet us at The Prince Regent on Tuesday, May 22nd, where you’ll get to meet some of the people behind LiquidPlanner, PLUS you’ll get an exclusive look at what updates are coming next. To RSVP, email Jennifer Ash at jen@liquidplanner.com.

Has this blog post got you thinking about attending the conference yourself? Just leave a comment telling us what else we should see and do in London once we get there, and we will send you our 20% registration code.

The countdown to London has begun, and we hope you’ll join us for the ride!

 According to the meetup group we played with the other day it is paper prototypes.   (You can see the whole list of techniques we discussed here, and the game we used to create the list here.) Ideas for DarkPatterns.org homepage
What we the criteria that got it up as the champion technique on the night?

• You can test business ideas with them
• Paper prototypes can be built quickly and edited just as quickly
• They can be disposed of equally quickly and with less fanfare than the deletion of an exquisitely crafted Balsamiq wireframe
• Pictures tell a thousand words
• Screen sketches capture key business data
• Screen and flow sketches capture important process and interaction flows
• The combination of the above help you discover edge cases
• A paper sketch doesn't get you caught up on details of design or UX

Here are some handy resources on Paper Prototyping

• Wikipedia page
• A case study on designing a University web application
• An online book - Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces
• A handy Youtube clip showing someone do it particularly well (embedded below)

The Business Is the Bottleneck By Ellen van Aken “Ellen, could you have this site up and running in about 2 weeks?” my clients often asked. “Yes, I could, but can you?” I always answered, “my experience is that the business, and that is you, is usually the bottleneck.” The client always looked a bit annoyed when I [...]

It would be hard to miss the sheer volume of applications being thrust into the market on any day. Apps seem to have grown to the point where everything you do in life requires an app to support it. Add to that volume of code being pumped into every device that you switch on and you are seeing an explosion of software the likes of which we have never seen before. Oil might be the commodity that the media talks about the most, but frankly software is the commodity that drives innovation in our economy.  Unlike the commodity oil, software is not found by exploration; instead it is created by a select group of people. The number of people who can create, manage and deploy software has a direct effect on its price and value. It therefore comes as no surprise that a crisis is looming.

For many people reading this blog, crisis may seem too strong a word – After all the oil crisis in 1973 left Americans waiting in line for gas, and as a child I remember the coal miners’ strike in the UK in the 70’s that let me spend Tuesday and Thursday afternoons at home.  They were real crisis’s – crisis that everyone is talking about. The situation with software surely is not of that magnitude! Well tell that to an employee of Blockbuster, Borders or Tower Records. The inability of those companies to exploit software fundamentally destroyed their business.  And increasingly it is affecting companies in other sectors ranging from manufacturing, to retail. Software is eating your lunch, and you don’t know it!

As software development pro’s we are perhaps the best placed to see the change. A change in our economy that has our friends, parents and even our dentist talking about their latest app, or how Groupon saved them money on a fantastic dinner. But unfortunately, though we see the change we seem unable to accept that this means our lives will have to change. We accept that we will have to use different technologies and programming models, but our jobs, the process that we follow, and how we collaborate with other practitioners will also have to change. For many Agile defines that change – describing a set of practices that will fundamentally improve our lives, allowing us to adapt to the unknown in a much more effective manner.  Agile does provide a great set of practices that help teams build software just a little bit better, but does not provide guidance for radical change of the complete value chain for software.  It does not equip our management with the tools necessary to manage the software assets inside and outside of their organization. Application Lifecycle Management does. It provides a management discipline to the practice of software delivery. But ALM needs to change in response to the crisis.

Perhaps the only other industry that has gone through such a transformation is the automobile. In the 70’s a fundamental change happened to the discipline of manufacturing. In response to changes in the market, the practices of Toyota made their business much more effective than those of their rivals. This led to Toyota becoming the poster child of the automotive industry, and Detroit having some rocky times that it has only just started to emerge from. The practices that allowed Toyota to succeed have been described as ‘Lean’.  The focus on reducing waste, whilst increasing value with empowered workers supported by information and techniques drove a different manufacturing process, but also sparked a revolution in many industries. It is time that ALM adopted those same principles. It is time for Lean ALM.

Still interested in the whole idea of Lean ALM? Come to the webinar http://tasktop.com/about/webinars on May 31 and hear a more detailed description of what it means.

Lets get the dialogue going…

Watch Tasktop webinars

Tweet

Problem Solving and Decision Making Processes By Alison Wood Decisions decisions….pros and cons…is the grass greener..? As a manager, you’ll run these questions through your head quite a lot. Wouldn’t the world be awesome if when you planned your project, every stage would be implemented and executed just as you had planned it? Unfortunately, the world out there [...]

Why do people register for the Stoos Stampede in Amsterdam?

Let’s try and make some educated guesses by using the champfrogs schale.

Curiosity

I am sure plenty of change agents are curious to know how this new kind of event will play out. Will it lead to actionable results for organizational transformation? Will it lead to nothing? No better way to know than to be there.

Honor

Maybe some will feel it an honor to be there. It will be the first “stampede” under the Stoos umbrella name. And there are already rumors that others will follow on other continents. It’s great to be among the first.

Acceptance

Some who attend the stampede might be looking for acceptance. I know that many change agents feel like aliens in their own organizations. But at this event they will be among similarly-minded people.

Mastery

The point of being a change agent is to become good at changing a little bit of the world around you. At the Stoos Stampede we will share stories about how to do this, which will help people to become more competent at it.

Freedom

Many people who are trying to change organizations are looking for freedom from command and control. The Stoos Stampede organization is exactly like that. There is (almost) no control. And lots of freedom.

Relatedness

There’s no better way to get connected with other people than face-to-face conversations where we inspire each other about organizational change. I’m quite sure this event will lead to lots of new relationships being forged.

Order

Ah, a tricky one. The people who crave for a bit of order should not feel disappointed. The stampede will not be a chaos. We will have some rules and constraints in place, to maximize the power of self-organization.

Goal

People who look for purpose won’t need to look further. Everyone who gathers at the Stoos Stampede is looking for ways to get happier employees and customers, and more meaning to running a healthy organization.

Status

Hm, this will depend on yourself I suppose. A change agent is only as good as the change he or she was able to introduce in the system. And status will follow if you did a good job at that.

What is your reason to come to Amsterdam on 6+7 July?

Kelly's Contemplation has a nice post on The 3 Phases of an Agile Project. He starts the example with receiving a project that has few actual requirements. The notion of a traditional - or better yet conventional - approach to project management starts looking for requirements. The agile approach is presented in a way that is typical of COTS based deployment through progressive development of the capabilities of the tool set tailored to the needs of the client.

Here's where traditional, er., conventional, project management fails to deal with the current approach to complex project, program, and product development.

I our Defense and Space program, there is a critical first step, that is baked into the procurement process.

CAPABILITIES BASED PLANNING

What capabilities does the customer want to posses when this project is over? These capabilities are the prerequisites to defining the requirements. Here's an end-to-end process for developing the capabilities description. This looks very non-agile, but these are the principles, put these into practice in a way that best suites your need. But check to see if you've covered off all the steps, because is something is missing, you may think you're being agile, but in fact you're missing a critical piece of data.

The critical reason for starting with capabilities is to establish a home for all the requirements. To answer the question “why is this requirement present?” “Why is this requirement needed?” “What business or mission value does fulfilling this requirement provide?”

Capabilities statement can then be used to define the units of measure for program progress. Measuring progress with physical percent complete at each level is mandatory. But measuring how the Capabilities are being fulfilled is most meaningful to the customer.

The “meaningful to the customer” unit of measures are critical to the success of any program. Without these measures the program may be cost, schedule, and technically successful but fail to fulfill the mission.

The process flow above is the starting point for Identifying the Needed Capabilities and determining their priorities.

Starting with the Capabilities prevents the “Bottom Up” requirements gathering process from producing a “list” of requirements – all needed – that is missing a well formed topology. This Requirements Architecture is no different than the Technical or Programmatic architecture of the system. Capabilities Based Planning (CBP) focuses on “outputs” rather than “inputs.” These “outputs” are the mission capabilities that fulfilled by the program.

In order to fulfill these capabilities, requirements need to be met. But we need the capabilities first. Without the capabilities, it is never clear the mission will be a success, because there is no clear and concise description of what success means.

The concept of CBP recognizes the interdependence of systems, strategy organization, and support in delivering the capability, and the need to examine options and trade‒offs in terms of performance, cost and risk to identify optimum development investments. CBP relies on scenarios to provide the context to measure the level of capability.

Here are the details of how to capture the capabilties needed by the customer. Again do these any the way the best suites your need. But do check that you've got - or are going to get - all the information. Otherwise you get to do the work twice.

Notice that most everything talked about in the post is here, plus some other stuff. Trade offs between capabilities is critical. Assessing the costs and the risks. It doesn't do anny good to charge ahead with everything the customer wants to do if you have no idea of the REAL costs and the REAL risk that is being created by your agile approach.

But defined capabilities through Use Cases and Scenarios is the standard approach in large defense and space programs. There is even a language for doing that - SysML is a systems engineering modeling language for Use Cases and Scenarios. I know that doesn't sound very agile, but on a multi-billion weapons systems (mostly software these days) scenarios are the starting point for identifying the actual requirements.

This is the core concept missing from the PMI approach, the dreaded waterfall approach, the conventional approach. And of course these approaches are no longer allowed in the procurement of system for the Defense and Space industry. Those places procure systems using Capabilities Based Planning.

The picure above is one of 5 processes we use in our Performance Based Management activities in our domain. Next comex the requirements, since we're spending the governments money, they want to know those sorts of things.

 

In the professional world where technology is omnipresent, we as project and... Conrado Morlan, PMP, PgMP

"Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for." - Socrates

But rememeber, you've got to provide attribution, otherwise they'll think you're a poser. Taking credit for others ideas as your own, or even embellishing them and calling it new is bad form these days.

Dealing with Conflict in Project Teams By Michael Stanleigh Team conflict is challenging for project leaders but it is not necessarily bad. Conflict can lead to new ideas and approaches and facilitate the surfacing of important issues between team members if it is managed well. According to various research studies on team conflict, the major sources of conflict [...]

LeanKit and Focused Objective announced a partnership to provide customers with an integrated product offering. The combined solution will bring industry leading quantitative analysis to LeanKit’s and Focused Objective’s customer base in an easy to use and immediately available way. This analysis includes forecasting project delivery dates, pinpointing what factors such as staffing, quality, scope change, etc. are having the greatest impact on delivery dates, and the ability to find what staff skill additions will have the most impact. “The ability to answer tough questions relating to date, cost, staff and ...

Altova announced the public beta launch of MetaTeam, a new team management and project collaboration cloud service. MetaTeam is a different kind of project management solution. It breaks down the mysteries of team organization into simple steps that anyone — not just project managers — can use effectively. Specifically designed to foster agile collaboration, MetaTeam makes teams more productive by creating an environment of transparency and information accessibility. At the same time, for larger teams and more elaborate projects it raises accountability and commitment by spelling out individual roles and responsibilities. “Altova ...

Get Started Using Social Media on Your Projects is a practical guide to choosing and setting up a social media tool in a project environment

Communication is always a problem on large projects: making sure everyone on the outside has a similar view of what is going on and that everyone on the project team knows how their role affects the others. You already have meetings with detailed minutes, phone calls with each team member, maybe even a dedicated intranet site, wiki or collaboration tool. What could a blog offer on top of all the communication you are already doing?

Here are 4 ways that you can use a project blog.

1. A blog by your sponsor

A blog can bring your sponsor closer to the project team: on a large project it’s possible that some members don’t even know who the sponsor is. It’s good to wheel out your sponsor when they need to inject a bit of motivation during a difficult patch, but it is rarely practical to invite them to every team meeting. A quick blog post from the sponsor will help the team members feel that someone high up does care about what they are doing, but without the intrusion of an email.

A large legal firm in the Southeast USA used this technique to engage project teams. The project sponsor added content to the blog several times a day. He used the blog to ensure that the team knew that he knew about their big milestones. It also helped build excitement towards significant milestones on the plan when the team knew they would be celebrating their success with events like go-carting.

The blog enabled him to stop sending out so many emails. It gave project team members more control over when they read the information. It also provided a forum for them to comment, ask questions and give their perspectives.

2. A blog to engage people outside of the project team

Another function for a project blog is to communicate to a wider audience than just your immediate team. Allowing other people in the company to read the ‘story’ of your project via a blog can help prepare them for the changes that may come when your project delivers its objectives.

Matt Down, a project manager from London, gives the following example of using a project blog as a communication tool:

For the last six months I have been using one to provide a brief weekly update on progress for the project team and other internal stakeholders. I normally include a relevant photo showing progress or an event that has taken place. I’m using Microsoft SharePoint which is the corporate tool we have for collaboration and have found it easy to use with a little guidance from another user at the beginning but otherwise no training. Using this rather than the weekly email I previously sent has been well received as people can look as and when they need the information and look back at what was said previously without trawling through emails. My only regret is I didn’t use it earlier in the project. I will definitely be looking to use something similar again on my next project.

3. A blog to help team members collaborate

My only regret is I didn’t use a blog earlier in the project.Executive postings on your project blog or on their general corporate blog can engage and invigorate the team and wider stakeholders, making sure everyone has the same vision of the overall goals. Great. But how can blogging help your team be better at what they actually do on the project?

This is an old-ish example, but still an interesting one, especially if you wish you could save time when documents are doing the round for being reviewed.

In 2006 I interviewed Paul Wormelli, who was then Executive Director of the Integrated Justice Information Systems Institute. The Institute is an industry consortium of companies that provide IT systems and products to the US Department of Justice. He told me how they had launched an enterprise blog in January 2005 using Traction software. The objective was to share information between the different committees.

Prior to setting up the blog, the Institute used to send out copies of reports for review in Word format. One person was nominated to collate the comments. Paul explained that if the document went out for review to 25 different people they would all pick up the same errors. The blog enabled the committee reviewers to communicate in real time. One committee was able to cut the number of phone and in-person meetings it held by half.

4. A blog to help team members communicate across distances

A blog can help the team communicate asynchronously – in other words, not in real time. A project blog offers a 24/7 informal reporting mechanism. Team members can post updates and progress reports to the project blog instead of calling a meeting to summarize progress. This can be especially helpful to those team members who do not have English (or the majority team language) as their first language and who find it difficult to contribute effectively during conference calls. They may be better at expressing themselves in writing.

Kandy Crenshaw has experience of using project blogs with team members in multiple time zones. She says:

I am currently managing 4 projects and have created Microsoft SharePoint project blogs for two of them. Originally, I intended to create a blog for each project but by monitoring the site analytics reports I quickly realized that the only staff members visiting the blogs were the core team members. Our project sponsors and outside stakeholders just weren’t interested in the level of detail provided there. The blogs were not (in my case) effective for sponsor and stakeholder communications. However, they have been an invaluable tool in projects with a large team based in multiple time zones. We have even used them to facilitate decision making between meetings.

As Kandy says, a project blog can help structure and organize project work and assist decision making. The ability to share views collaboratively can also help combat the silo mentality that grows up around projects. A blog is a level playing field, owned by the project and not the IT team, and easy enough to use for everyone to feel they can get involved.

How do you use blogs on your projects?

This is an edited extract from Get Started Using Social Media on Your Projects (3rd Edition). I have recently revised and updated the ebook. The latest edition has over 15 additional pages of good stuff including lots on privacy and security considerations of using social media on your projects.

Get your copy here.

Related posts:

1. Blogs and budgets So the ITtoolbox blog awards for 2006 have been announced, and none of the winners are from their project management category. Perhaps I shouldn’t be...
2. Keeping up: New ways of working This mini-series is looking at how project management is facing the challenges of 21st century business practices.  Missed last week’s article on how project management...

I've posted about him before, but if you're not reading Jeff Atwood's Coding Horror blog, you're really missing out. Today's post is perfect. There are several lines that really stuck with me, here is one of my favorites:
Please don't advocate learning to code just for the sake of learning how to code. Or worse, because of the fat paychecks. Over a year ago, in response to one of my posts here on the site, someone told me that if I didn't like how developers did their jobs, I should go out and write the code myself. The idiocy of the statement just astounded me. Now, here is one of the premier programmers in the world, backing me up.

You see, learning to code is very similar to business analysis or project management. It may sound like something that anyone, given a weekend and a 'Teach yourself XXXXXX in 24 hours" book can do, but learning a programming language does not make you a developer, nor does learning the concepts behind business analysis or project management make you either one of those professions.

My biggest concern is that most everyone should not learn these skills. To quote the movie Tommy Boy:
Tommy: I can get a good look at a T-bone by sticking my head up a bull's ass, but I'd rather take a butcher's word for it.  Most business people shouldn't need to know more than the basics about technology and they definitely shouldn't know enough to try doing project work, at least not beyond being a SME. Its not that these people are dumb, far from it, but their expertise is in running the business. Those of who work on projects, developers, analyst and PMs, have our areas of expertise as well. Some of the skills overlap, but lots more do not.

With my background as an analyst, I do tend to see everything through that lens. When I'm in a meeting to discuss a recently discovered problem or opportunity and the first thing I hear is someone say, "What we need to do is..." I find myself trying to breathe deeply and not lose my temper. Starting at the solution without really getting a firm understanding of the problem is one of the worst mistakes you can make when doing analysis. It is a very easy failure to make, one I see analysts make regularly, but one that you have to train yourself out of in order to be the best at what you do.

Be an expert at the things you're really good at and leave everything else to the experts in other fields. When we work together as a team of experts in our own field, we do better than a bunch of amateurs who don't know enough to know they don't know what they're doing.

May the 11th I participated to the #Agilmente conference organized by the PMI NIC in Portonovo (a wonderful place at the mediterranean sea), in collaboration with club ti Marche (@clubtimarche) and Controller Associati Ancona. In that occasion I had also the pleasure to give a talk named “Agile project management: a trade-off between pro-activity and re-activity“. [...]