Feed on
Posts
Comments

When ‘Agile’ isn’t really Agile

Oct 26th, 2011 by

Heading home on the subway after a late meeting, and picked up the free evening newspaper. I was standing on the platform flipping the pages, reading headlines, and glanced up to see a familiar face on the platform looking back at me with that “don’t I know you?” look.

“Vladimir, how are you?” I exclaimed, shaking hands with a fellow networking buddy. We quickly caught up on where we were, what we were doing. Vlad had now landed a role with one of the big consulting firms after a lengthy stint consulting overseas.

“You’re doing Project Assurance? What’s that?” he asked me. He got my elevator speech -  ”Project Assurance helps manage risk and improves delivery confidence” - and how we’re more than an audit service, think of us as the family doctor going along for the ride for the life of the project or program. Fire Prevention hopefully, more than Fire Fighting.

The subject of waterfall versus agile development arose. Vlad was learning the ins and outs of their in-house Agile development practices. He was curious about my experience with Agile. I pointed out I did have a recent experience with an Agile development team, where work was outsourced to a local company. My experience was the developers liked Agile because they could rationalize not developing any documentation, after all it’s about developing code quickly, and documentation just gets in the way. Which is anathema to me. (I am a big fan of what my friend Julie strongly preaches, “If it’s not written down, it doesn’t exist”.)  Based on that experience, I explained to Vlad, my spidey senses start tingling whenever I hear ‘Agile’.

Vlad commented with a similar observation (!). When he asked the inhouse Agile developers about documentation, similar response, “Oh we don’t produce documentation.”

Generally, Vlad and I agreed that the customer – the person signing the cheques, you know, paying the bills? – has the right to documentation. At minimum, proving traceability, from requirements to code to testing. And also to provide a blueprint for maintenance and enhancements. “The code is the best documentation”, just not acceptable to Vlad and I.

Also, a stated advantage of Agile is that code would be reviewed with the customer on a daily basis as it was being built. But I never saw that happen, on a daily or weekly basis. So, what did I see? Weak waterfall, minimal documentation, rebranded as Agile.

I trust you can see why I might grimace when I hear the phrase ’Agile development’. I hope you do too, enough to read up on what proper Agile management is intended to be. And don’t let the coders bully you (especially if you are or represent the person signing the cheques) that documentation is not required. In fact, build it into the SOW and into the cost of services.  Without this, you are open to being held hostage by the developers. You then have to talk to them to learn or know anything, which is an unreasonable risk for any corporation to accept. When they depart, you will have no documentation on the system for maintenance or enhancement. And while we can make many excuses for this happening decades ago, no excuse for this happening in the 21st Century. We are supposed to be smarter.

And I reached my stop before Vlad did and we parted company. But not before we made plans to get together in a few weeks after he’d settled down again after returning home for good.

Posted in Documentation, Procurement, Project Management, Scope, SDLC | 4 Comments »

Exceeding Expectations

Jan 1st, 2011 by

St. Petersburg, Russia. August 2002

We’d just finished the second day of tours and our bus had arrived back at our cruise ship, the Marco Polo, a cosy 1,200 passenger liner, docked in a very remote area of inactive industrial waterfront. We were greeted by a 5 man brass band, appropriately costumed, playing lively traditional Russian music. We had encountered this type of band at many of the palaces and museums we’d visited. Now, it doesn’t break me to tip them a dollar. But consider even a quarter of the passengers tipping a dollar, the band getting that several times a day, each day during tourist season. It would probably make a big difference in their lifestyle living in Russia, which was emerging from years of totalitarian rule, and as we were seeing and learning, was presenting many challenges to the average person.

So, many of us dropped a tip in the bucket hanging on the post as we approached the gangplank, nodded and smiled, and the band members nodded in return as they continued playing.

But that wasn’t the end of it.

7:30pm, after dinner, I wander up to deck level to watch the proceedings as we cast off to make our way to Helsinki. And I notice the band is still there on the dock, milling about, near their tiny Lada. The gangplank has been lifted, so I have no idea what they are still doing there.

As the ship starts to slowly pull away from the dock, the band gathers up their instruments and starts to serenade us. I think I recognize the tune – Dasvidania – which means goodbye in Russian. And as the ship is pulling away further from the dock, the band is playing with increased intensity. At this point, the small crowd on deck to witness our departure is all eyes and ears on the band. The song comes to an end, the five musicians face the ship and bow. And the small crowd on deck breaks into a lively round of applause and cheering.  (And then the band crammed themselves and their instruments into that tiny little Lada and drove off.)

I saw many amazing things in St. Petersburg those two days, but this occasion stands out in my mind. I keep asking myself, why, why did they stick around? There was no opportunity of getting any more tips from the passengers. They probably waited over 2 hours to play for us. Were we that gracious with our tips? Was it their special way of wanting us, as I am, to speak of a special experience that a visit to Russia can provide? (I have friends with comparable stories). This was something I did not expect, and it is a warm special moment of my visit to that city.

(We might call this putting a WOW factor into your project – it doesn’t always take a lot. Sometimes it’s just doing a little extra, the unexpected.)

Posted in Project Management | No Comments »

Better Team Collaboration – videoconferencing on the cheap

Aug 15th, 2010 by

Julie was beaming as she entered the restaurant and walked to my table. “Great to see you, it’s been a while!”

“Yes it has”, I said, “we’ve left it too long. How are you doing? What’s new?”

In addition to successfully completing a major installation, she was thrilled that she was now able to work more collaborativelly with the other half of her team in Calgary. When they’re doing white boarding in Toronto, the folks in Calgary can now see what’s going on, they’re not just staring at a speakerphone on their end. “Aha, so your customer finally sprung for a video conferencing room,” I said. “Nope”, she replied. “They’re letting you use Skype?”, I guessed. “Heavens, no! The machines are locked down, we couldn’t install it if we wanted to, and anyways it’s non-standard software”, she said, “but what I’ve got works just as well, and it doesn’t matter what meeting room I’m in. Let me explain”

Her solution was rather simple, making use of inexpensive off-the-shelf products.  Here’s how it worked.

At the Toronto end, the meeting room required a conference phone, a network connection, a laptop/PC and a video camera. At the Calgary end, everything but the camera is required. The camera wasn’t anything fancy,  it was in fact a rather aged Logitech laptop video cam. And she had collaborative meeting software (GoToMeeting, but WebMeeting or Webex will also do).  Enable the video cam. Point the camera at the whiteboard. Select as large a window as possible to fill the laptop screen with the videocam picture and still maintain clarity. Start a web meeting at the Toronto end, have the other participants join in the meeting. Share the desktop. Enable the conference bridge on the telephone. The participants accept the meeting, you’re in business. If there are several attendees in a meeting room, connect the PC to a projector and it’s almost like they’re actually there.

Hmmm, I commented, now if you had only two sites in the meeting, you could video conference between the two sights by building a second instance of this setup, but reversing the Toronto/Calgary roles, the receiver now becoming the originator for the first site. And, because the equipment is not bolted to the ceiling or the table like in a special video conference room, you could do this from any meeting room where you had a network connection. Very interesting!

Julie continued, “And, with this little camera, every time we’re on GoToMeeting, I can pan the camera around the room and let the attendees see who is at that end. I can give the other end control, they can turn their camera around the room, and we can see who’s there. It helps team building, putting a face to the name. Yes, Skype would be simpler, but…”

Lesson learned – be creative, use a lot of simple components that you probably already have, just put them together to make it work.

“And look at my new iPhone”, Julie said, ” I can make a video phone call, just like the Jetson’s cartoon. Amazing, we often have stuff for ourselves that’s so hard to get for the office. Anyways, let’s eat. What’s good here?”

Posted in Communication, Project Management | No Comments »

Not tracking Business Project Costs? Why Not?

May 24th, 2010 by

My friend Bob had that lost look on his face again. ‘What is it this time?’ I asked.

‘We’re not tracking project costs’, he started. ‘It just doesn’t make any sense. How can we learn to estimate better in the future if we’re not tracking the cost of existing projects?’ I countered, ‘That’s not what you told me last week. You have your project schedule, the task list, estimates AND actual hours per resource on each task (excellent integration of your time reporting with your schedule, by the way), cost reports by week, and ongoing project costs tracked against planned cost and baseline. What’s missing, Bob?’

He looked up,  ‘What’s missing is – I cannot understand why the Business side of the project isn’t tracking their costs just as diligently as I am for IT. Construction projects track all their costs. Military and defense track their project costs like hawks. I see an IT project in support of business monitored very closely, and I don’t see equivalent monitoring on the Business side. I’ve read the book ‘Quality is Free’ am I missing something that Business project costs are somehow ‘free’?

‘Oh that’, I muttered.  I had to admit I’d seen the same thing in different organizations. The Steering Committee reports did an excellent job of documenting project costs for IT, but there was nothing on business costs. So, what was the true cost for the project? Nobody really knew. Valuable information is lost, as nothing is finding its way into project archives to help decide whether or not do a similar project in the future – based on TOTAL cost. Why would you decide to do a similar project again strictly on the basis of IT costs only?

I did have an answer for Bob and shared the information I’d gathered when I had asked the question in the past. The cost of business employees is looked upon as ‘sunk’ costs, because those employees are operational. The costs are unavoidable. So, they are not tracked or recorded against specific activities.

But here is the flaw in applying that logic, and  I shared with Bob an argument I had often raised in the past when I had Business PM accountability. When the business employees are working on a project, these are no longer operational costs, these are project costs. If their activities take a little longer than planned, i.e., the cost has just gone up, there’s no monitoring. And if these are activities in partnership with IT, IT does have to answer.

I shared some good news with Bob, though. There is change in the wind in some places. I do have one colleague, managing Business PMs, that has started tracking the hours her business staff is spending on projects. So all hope is not lost. Change can happen.

Bob shrugged and opened his menu. ‘Would be nice if everyone did. Let’s eat.’

Posted in Cost, Project Management | No Comments »

Consider VARK and improve your documentation

Apr 18th, 2010 by

VARK stands for Visual – Aural – Reading – Kinesthetic. It refers to the way people learn. It’s worth understanding VARK because it can be very helpful to reaching your audience and I suggest it may influence how you prepare your project documentation. Let’s examine each and provide some ideas on how it can be used.

Visual – show it to them. Think Powerpoint presentation. Think diagrams. “A picture is worth a thousand words”. A large percentage of people are visual. Include diagrams, tables, process maps, flow charts,  in your documentation where ever possible to enhance its value. When I’m scanning a large document the first time, guess what catches my attention – diagrams and tables. They can convey a lot of information much faster than having to read pages of words to explain the same thing. Try it – take a diagram and try to explain it in words – tedious isn’t it?

Aural – let them hear it. In a classroom, this would be the teacher / professor lecturing at the front of the class.  To produce ‘audio’ documentation, connect a video camera to your PC and record a movie of yourself explaining the documentation.  I created a handover video after the meeting was cancelled and rescheduling was not an option.  With the stack of binders and manuals I’d produced at my side, all clearly labelled, I identified the document, explained why it was created, why they might want to use it, and what the document contained. Yes, softcopy was also left with the customer. There is about 20 minutes of video explaining the documentation for anybody, at any point in time in the future, to playback and hear the Subject Matter Expert (me) lecture on the documentation. An exercise for you – what else might you want to video and playback at future dates? Maybe the kickoff presentation for your project, useful for new members joining the team? Hint – store the video with the softcopy documentation.

Reading – exactly what it describes – old faithful – write it down, some people learn best by reading, the lecturing, the presentation doesn’t work for them. My wise friend Julie taught me, “If it isn’t written down, it doesn’t exist.” Not a lot to say here, except learn to write well. Practice by blogging (yes, it helps). An interesting test of your writing – hand it to an average Grade Eight Student and ask them to identify any sentences that just don’t sound right. I had my son do this for me; it didn’t matter that he did not understand the terminology, he did find some confusing sentence structure that I modified to improve the readability.

Kinesthetic – learning by sense, by feel, by touch, by smell, by doing. In the traditional education environment, this would describe Woodworking, metal shop, sewing, baking, etc. Winetasting – taste AND smell. How do we leverage the Kinesthetic aspect of learning to enhance our documentation? This really depends upon what you are documenting. If the shoe fits, provide samples of what you’re dealing with, to evoke touch, feel, smell. Kind of hard to do with software, though. With project management training, this could be role playing, practice completing templates, group exercises.

VARK – you have a new item in your documentation toolbelt now. Consider your audience – consider what works best.

To learn what your VARK score is, how you learn best, visit http://www.vark-learn.com/

Posted in Communication, Documentation, Project Management | No Comments »

The Project Archives – Low Hanging Fruit – Make New PMs Productive Faster

Mar 21st, 2010 by

We mentioned in a past post that Project Archives can be a gold mine of information. Which brings us to that famous radio station WIIFM – what’s in it for me? What are the benefits of a project archive? In this post we’re going to take a look at what must go into a project archive to make it valuable – let’s avoid garbage in, garbage out.

We need a starting point so we’ll assume the Project Manager must create and maintain a Project Notebook during the life of the project. This includes the Project  Charter, Project Definition Document, Statements of Work, Vendor Agreements,  Status Reports, Issue Log, Risk Log, Change Requests, Schedules, Budget and Cost Sheets, Approval Documentation, Project Closure Reports, Lessons Learned, Compliance Reports, Audit Reports.  (While not part of the project notebook, ensure the following documentation is also being produced from the System Development Life Cycle (SDLC) or Project Development Life Cycle (PDLC) process – requirements, design documents, specifications, quality assurance, quality control, etc.).

Ok, so I have the archives of say over 50 projects to look at, now what? WIIFM? Well, if you’re a PM or manage PMs, this is what’s in it for you.

Leverage the archives to help new project managers on the team productive faster.  The archives provide examples of how to create the documents in the Project Notebook – what has been produced and what (hopefully) presents acceptable standards. If you are a new project manager joining a PMO or PM Centre of Excellence,  this cuts down on your startup time. ASK what past projects were similar to yours and which provide a good example of ‘how to’ produce these documents.  You’ll spend much less time figuring out what is acceptable or not. You’ll produce the documentation quicker. There will be less of “that’s not how it’s done here”. And you’ll be delivering value to the organization that hired you much quicker, whether you are contract or full time. Everybody wins.

Posted in Documentation, Project Management | No Comments »

The Project Archives – A Gold Mine of Project Information

Feb 14th, 2010 by

Over the years, I’ve managed projects with many companies and witnessed the full spectrum of maturity with regards to the attention organizations pay to project documentation and preserving it in an archive for future use.

Some archive only hard-copy and don’t care about soft-copy – self-defeating in my opinion, it takes time to eyeball dozens of documents when looking for past examples versus a quick search. Others give half hearted attention that proper documentation is produced during the project and even less once the project is finished, yes it would nice if we had a proper online archive.  Some have great document management systems and processes but don’t enforce or monitor their use. Some do it very well using only a simple file system folder structure. Hmm, if we have a consistent structure for storing project documentation during the life of the project, the archive essentially evolves during the life of the project and it’s available for reference immediately once the project is over. For that matter, it makes sense to have the documentation of unrestricted projects available to all project managers, so they can leverage and learn from the experiences of the other projects. Sharing, opening up, not keeping things a secret –  the spirit of collaboration.

Let’s examine archives from the perspective of who, what, when, where, why, but not necessarily in that order.

Why you would archive, a number of reasons – to conduct project audits at any time, meet compliance standards, gather knowledge on project profiles for your organization to help in a number of areas, i.e. estimating. Another important ‘why’ is that there must be negative consequence to not archiving, with regards to my observations as to where it has worked successfully and where it has not. Example – a negative consequence of not producing and archiving the Projet Notebook is the project manager fails to receive signoff on the Project Compliance Audit when closing the project. What to archive would include the contents of the Project Notebook – the Charter, Work Order, Project Definition Document, Statements of Work, Vendor Agreements,  Issue Log, Risk Log, Change Requests, Schedules, Budget and Cost Sheets, Approval Documentation, Project Closure Reports, Lessons Learned, etc. (While not part of the Project Notebook, ensure all documentation from the System Development Life Cycle (SDLC) or Project Development Life Cycle (PDLC) process is also archived -  requirements, design documents, specifications, quality assurance, quality control, etc. Who produces the archive – a central body (PMO, Project Auditors) enforces the creation of the archive structure. The project manager monitors filing of all documentation. Any project team member may produce documentation. Where would you archive – using a formal document management system provides secure and shared storage of information. At minimum a standard folder structure for all projects is advisable. When is the documentation produced – enforce a Project Compliance Audit shortly into the life of the project to ensure the project manager has created or started to create the mandatory project documentation to meet Compliance to Standards. A sign-off required on a Project Management Compliance Audit at the end of the project ensures the document will be completed and filed.

So we’ve answered some basic questions about archiving – why do it, what should it include, where should it be stored, why it should be done, when to do it.

In future posts, we’ll examine each of these and provide even more insight into the value of project archives to project managers, project team members, and even senior management. This gold mine of project information is not just for the project managers.

Posted in Closeout, Documentation, Project Management, SDLC | 2 Comments »

Video – Another Way to Create Documentation

Jan 30th, 2010 by

You’re familiar with the usual media for documentation – hard copy, softcopy – on CD, on the server. And it’s a pile of documents, a lot of words, some diagrams and tables. You read the words, highlight what’s important as you go along, make some notes, and you try to understand the material. Thought – wouldn’t it be great if you had a little more insight from the person who actually created the document?

We have the technology to do so and it’s cheap and easy. Consider creating a video. Look at Youtube. If you want to learn how to play bar codes on a guitar, or play blues on a harmonica, you could get a book and try to learn how. Or you could logon to Youtube and watch somebody show you how. You get more out of video as a source of information because it makes greater use of senses – sight AND sound – to communicate. Checkout the numerous webinars on Youtube – the value start to become obvious.

If you’ve made a video on your laptop, then you have the tools and the skills. A better camera will provide better quality video. Consider a pin-on microphone to ensure a good audio recording. Warning – you may discover your don’t have a career as a newscaster. Try adding vocal variety. Put on a happy face.

On a contract assignment, I found video documentation to be a lifesaver (for my customer), when the project handover meeting was cancelled, with no opportunity to reschedule. The company was small and growing. At some point in the near future, I was confident all that material  would be handed over to somebody and told ‘you own this now – run with it’. Challenge – ‘somebody’ wasn’t at the Handover meeting, and no guarantee I would be brought back to explain it. So I did the next best thing – created a video of what I would have said at the Handover Meeting.

A few test runs established the proper lighting, camera angles and audio levels. Following a high level script for the video, each document (clearly labelled) was shown to the camera, explained why it produced, what it contained, how to use it, and why they might want to use it. Result – my customers had a video of what they would have heard at the handover meeting. And for anyone who needs to use the documentation in the future, my smiling face is there in perpetuity to help them along.

What else might you want to video for playback at future dates? Perhaps the development of those complex formulae behind the business rules, that would make for so much dry reading in hard copy. Maybe the kickoff presentation for your project, which would be useful for new members joining the team.

There are no boundaries – your imagination is the limit. And who knows – you may discover you could have a career as a newscaster.

Posted in Documentation, Project Management | No Comments »

Use Learning Toys to get better results when facilitating

Jan 17th, 2010 by

There’s a bulky red cloth bag that forms part of my project management toolkit. It’s filled with small slinkies, smiley face stress balls, plastic building blocks, twisty snakes, and a variety of plastic knick knacks. This is my bag of learning toys, which I assembled years ago for my project management teaching assignments. I’ve used it ever since when I’m facilitating workshops or brainstorming sessions.

The purpose of the learning toys is to help people exercise both sides of their brains in a working session. Yes, it’s the left brain / right brain thing. Your left brain is the logical side, right brain the creative side. Left brain thinks in parts, right brain thinks on the whole. Generally, most people tend to think in parts – their job, their responsibilities, their own silos. So the need to have them think about detail will be satisfied. The challenge is in getting them to think about the big picture – the whole – to exercise the right side of their brain, and to think about their part in the context of the big picture. This is where the learning toys, which exercise the right side of their brian, the creative part that looks at the whole, come into play.

The toys can also have an added dividend to support team building. I’ve had the group separated into teams, split the toys, and asked them to each create a work of art with the toys they were provided. There were some ingenious entertaining creations produced, using the toys in ways they weren’t intended to be – hey that’s thinking outside the box. The toys have also brought out the jugglers in our midst. One of my team leads uses juggling to help her improve her puck handling abilities to play goalie for her ice hockey team.

Where do you find these learning toys? Dollar stores and discount stores are the best bet. Tip – the small slinkies are very popular – stock up on them when you find them.

The toys also inject a little fun into the workshop. Yes, at first there are threats (or reality) of pelting the facilitator with the stress balls if the sessions gets boring.  I’ve also noticed the attendees absent mindedly toying with the slinkies, squeezing the stress balls, fiddling with the building blocks. It seems to calm them, to relax them, which helps them think better. If you are using learning toys, I suggest allowing the attendees to take one of the toys to keep when the session is over. It’ll be a reminder of the fun they had at your workshop, working on your project. And when the word gets around it’s fun to work on one of your projects, you’ll have people, including the best, wanting to work with you.

Now excuse me while I hit the road and visit a few dollar stores – I was almost cleaned out of slinkies and twisty snakes after the last session.

Posted in Human Resources, Project Management, SDLC | No Comments »

Thread Your Project Requirements To The Test Cases

Jan 10th, 2010 by

Recall the post about improving Vendor written SOWs? The message was to first document your requirements and second ensure there was a thread from Requirements to the Work being performed by the Vendor. Note: this doesn’t just apply to Vendor written SOWs but your own as well. Now, let’s take that concept of creating a thread another step – threading requirements to test cases.

For every requirement, there must be a test case to validate the requirement  has been delivered and it functions as required. And vice versa, the test cases created must align with a requirement, else why were they written – wasted effort, wasted dollars. If the numbers are not very large – not a lot of requirements, a single tester, short testing period – the record keeping is manageable with basic tools and without becoming too sophisticated (word processor, spreadsheet). But when requirements number into the hundreds or thousands, a test team of more than one person, testing which will last for several months, time to move on to more sophisticated processes of testing and methods of record keeping.

To start with, it is highly recommended to number your requirements. This makes the record keeping and reporting simpler to manage. As an example, TR001 for Technical Requirement 001, FR003 for Functional Requirement 003, etc.

There are tools that align to this discipline and can make the job easier for you – tools that permit recording of Business Requirements, alignment with Test Cases, test results, the ability to produce a variety of reports on test results and even a test results dashboard.  The benefits of centralized tools are that the Quality Assurance / Testing team, the projects managers and any other stakeholders invited to monitor testing progress can do so by viewing the testing dashboard at their discretion.

If you don’t have the tools or the budget, roll your own. While this will require a tad more manual effort, the discipline can still be applied.  There is the option to use a spreadsheet, or if the mood strikes you, create  a database, which would provide the ability to produce a broader range  of  and more flexible reports.

If you are fortunate to have the budget to purchase tools, or would to know what to budget for, there are a number to choose from.  There are tools to document requirements, test cases and defects, and that provide the thread across them all. There are also guidelines for integrating tools from different vendors, if that’s what you have inherited. We suggest performing a search on the following tools (Mercury, ClearQuest, RequisitePro, TestDirector, WinRunner, LoadRunner) to find out what is available.

Happy Testing!

Posted in Documentation, SDLC | 1 Comment »

Older Posts »