Monday, June 28, 2010

Fostering Team Performance and Loyalty

There’s an old adage that goes something like this, “people don’t care about what you know until they know that you care.” This is a defining belief of my leadership philosophy and one that I seriously observe with my direct reports. As a boss, your subordinates want to know that you care for them as people and not just headcount, a practice that has become all to common in light of today’s recessionary times.

While working at one of my former employers, my practice in this area was brought to the attention of HR leadership and at least two articles were written about me and my method of fulfilling this adage. You may think what I’m about to share with you is a little silly at first, but believe me it works! I must admit however, that the idea didn’t originate with me. I read about it once in a magazine article written by a young woman who developed this very technique in her rise to a corporate VP position. Once I learned her technique technique, I applied it at every company I worked for since whenever I had direct reports.

When I take over a new team, one of the first actions I perform is to conduct one-on-one meetings with each team member. The purpose is to get to know them better and for them to get to know me better. During that early session I ask five questions:

  1. What is your favorite candy bar?
  2. What is your favorite drink at work?
  3. What is your favorite drink outside of work?
  4. What is your favorite place to shop?
  5. What is your favorite activity that you can speak about in public?

I save each of these answers in their folder and use them to supply personal rewards and recognition whenever their performance merits it. For example, if someone works very late into the evening to keep a promise to a customer, they might find their favorite candy bar and a personal thank you note from me on their desk when they arrive at work the next day. It could also be a cup of their favorite coffee or a gift card to Starbucks. The idea is to show that you noticed what they did and you appreciate the effort. If they observe seasonal holidays, they might receive a gift certificate to their favorite store or to enjoy their favorite activity. It’s all about fostering a good relationship with those who work with you.

Of course, with budgets as they are these days, the cost for these little tokens of appreciation come out of my own pocket. Some of the most appreciated gifts are the simple notes I’ve written. Sometimes I’d go to my boss and ask him/her to write a personal note to the intended recipient. Thank you notes cost near to nothing to write and yet produce immeasurable value.

The biggest problem I ever encountered with this technique is procurement. I’ve had direct reports who grew up outside of the United States. Their favorite candy bars are only available in their home countries. I’m so thankful that I worked in a global environment and developed friendships across the world. I often called some of my friends and asked them to send me cases of whatever candy I needed for a particular person. Believe me, the effort you’ll go through is worth it. Your team will respond well when you treat them kindly.

Saturday, June 26, 2010

Experience the Gift of Giving

This post is a little different for me. Normally, I write about leadership, computers or the SDLC. Today I want to switch gears and reflect on the gift of giving through the appropriate use of our talent(s) which is defined by Merriam-Webster as “a special often creative or artistic aptitude.” I believe every human being has been endowed by our Creator with some innate talent that can be used to be a blessing to others. Some of us are powerful speakers or writers, others warm hearted, hospitable and friendly; and yet still others artistic and creative. What do you do with the talents you’ve been blessed with?

Since my teenage years, I’ve loved performing before an audience. I’ve acted in community theater, have been on TV, ran for an won a minor political office, have been written about in newspapers and have performed music in front of live audiences, some very large. For the longest time, I enjoyed doing it to satisfy some selfish need in me. I don’t know what it was, I only know I enjoyed receiving the applause of a generous audience.

Something has changed in me though…for the better I pray. As I’ve grown older, my values have shifted dramatically. Instead of performing for me, I now perform to bring joy to others. I care more about the happiness I can bring to an audience which in turn allows me to receive greater fulfillment than I have ever known before.

At least once a week, I perform with a group of like-minded individuals to bring a little bit of happiness to people living in nursing homes and long-term care facilities in the Raleigh area. Our typical audience runs from about 30 to as large as 100 people. Sometimes, if the home experienced a recent death of a resident, there may only be as little as 3-4 present which is smaller than our group. We perform Gospel music, some bluegrass and easy listening oldies for people who have been largely abandoned and forgotten by their loved ones. Each one of these people has a story. Each story is enough to tear your heart out. Some folks are very old with little time left on this earth, and they tell you straight up that they are just waiting for their homecoming. Others are very young, confined by their disabilities or illnesses for the rest of their lives. Some are visited by their families every week, some once a month and some never. There are even some married couples who live in the same home, but in separate rooms on different floors. It’s not an existence I would want to wish on anyone.

The interesting thing about performing is that you never quite know if the audience is enjoying themselves while you are on stage. Sometimes, the audience sings with you. We even have nursing home where an elderly blind resident sometimes brings his harmonica with him and we play back-up to his lead. He can only play in one key, but the group loves it nevertheless.

The highlight always comes at the end when we are packing up our instruments and resident after resident come up to us and hug us, kiss us, shake our hands and tell us that the hour they spent with us is the highlight of their week. It’s also the highlight of our week. They enter the room downtrodden and depressed, but leave with smiles on their faces and a slight bounce to their step, if they’re ambulatory that is. I wouldn’t trade it for anything. That’s the true gift of giving…when the talents you have been blessed with are used to bring joy to others. Have you ever experienced such fulfillment?

Wednesday, June 23, 2010

Excellent Book Reviews So Far

Writing and publishing a book can be a long, drawn out process. One of the steps that must be performed before the book goes to press is the “peer” review. A little over a month ago, I sent the book out to five people to look it over and comment on the content. So far, we’ve had two of the five send the reviews back. Here’s what they said:

"This book is a great roadmap to anyone developing a System Development Life Cycle. It's contains a wealth of research, comparative analysis and valuable lessons learned from someone who's been there, done that. The information compiled here by the author will save you time and money. I especially liked the Handy Desk Reference loaded with useful charts and graphs" —David Nilsson, Architect Principal Leader, Computer Sciences Corporation

“The author has truly ‘hit the nail on the head.’ Whether you are an academic student who is aspiring to be an IT professional one day, a trainee that has just started career, a business & quality analyst and manager that has years of IT SDLC project experience—a must read for an IT professional at all levels of IT journey” —Sekhar Bommana PMP, ITIL, VP – Strategic Solutions & CoEs, Infomerica, Inc.

I’m anxious to learn what the others think as well. I’ll keep you posted.

Friday, June 4, 2010

The SDLC is Not Just for Software

There was a recent question posed on LinkedIn about what the acronym SDLC means when you see it in a job posting. The question was asked by a person identifying themselves as a job-seeking business analyst. I followed the thread with amusement as the many responses were posted, none of which answered the question adequately. Of course, I couldn’t resist putting in my two cents only to have someone snidely remark, “It’s good to hear from a self-proclaimed expert on the SDLC.” The commentator then went on to offer badly formed advice. It is very amusing!

The truth is the SDLC is not just about software. While software is a major focus of any SDLC, it is not the only focus.  That’s why I prefer to define the acronym SDLC as System or Solution Development Life Cycle and not Software Development Life Cycle. To do otherwise is a misnomer. Need proof?

Think about all the projects an IT organization takes on. It doesn’t matter if the project is in telecom, infrastructure, application development or even outside of IT as in opening and outfitting a Greenfield location. True or False? All of these projects have certain process commonalities that can be governed by an effective SDLC. Every project needs to:

  1. Elicit and analyze requirements
  2. Develop design specifications
  3. Define success metrics
  4. Produce clear, consistent and unambiguous artifacts
  5. Deliver products that comply with the highest quality standards that meet or exceed customer expectations
  6. Transfer knowledge to operational support and maintenance personnel, sometimes to outsourced, off-shore locations
  7. Train end users and support resources
  8. Offer post deployment support and maintenance

All of these development aspects are governed by a well-defined and effective SDLC. It doesn’t take a giant leap if faith to conclude that the SDLC is not just about software.

Wednesday, June 2, 2010

Contents of the Book

There has been so much interest in what is written in “Principles for Maturing Your System Development Life Cycle: The Ultimate Guide to the SDLC” that I’ve decided to publish this descriptive table of contents. I hope it satisfies your curiosity, but if you have any further questions, please feel free to send me an email.

•    Forward
•    Chapter 1—Introduction
     o Rationale and purpose of the SDLC
     o Organizational change management and its impact on the successful implementation and adoption of the SDLC
     o IT Governance and how the SDLC’s processes help decide IT Investment opportunities
     o Project Management method and its synergies with the SDLC
     o Compares the project management triangle (i.e., scope, time and cost) to my invention of the SDLC triangle (i.e., quality, consistency and product delivery)
     o Compares the five basic process groups of project management to the five basic process groups of the SDLC
     o Ties it all together by presenting my third invention, my theory on the three-legged stool of IT business value: IT Governance, Project Management and the SDLC
•    Chapter 2—System Development Models
     o Discussion of team empowerment
     o Historical look at the evolution of twelve traditional waterfall, agile and hybrid development models to examine shared commonalities and best practices
     o Waterfall, Modified Waterfall, the Spiral Model, V-Model and Dual V-Model
     o RAD, Scrum, Crystal, Extreme Programming and Dynamic System Development Model
     o Incremental Commitment Model and Lean Philosophy
     o Best practice comparison charts
•    Chapter 3—Requirements Maturity, IT Governance & Planning
     o Poor requirements and project failures
     o Importance of business analysis training
     o IT Governance
          Structure
          Work intake and the requirements process
     o Requirements Process
     o Importance of Requirements Maturity
     o Requirements Planning
•    Chapter 4—Requirements Elicitation
     o Requirements Elicitation Activities and Techniques
          Brainstorming
          Focus Group
          Interview
          Observation
          Prototyping
          Modeling standards: UML and BPMN; Emerging standard: SOMF
          Requirements Workshop
               Managing Scope Creep
          Survey
•    Chapter 5—Requirements Documentation & Quality
     o Requirements Documentation
     o Business Requirements Definition
     o Good Requirements Quality Checklist
•    Chapter 6—Requirements Analysis, Inspection & Tracing
     o Document Analysis
     o Interface Analysis
     o System Requirements Specification
     o Quality Assurance Inspection Stage Gate
     o Baselining Requirements Artifacts
     o Traceability Matrix
     o Requirements Phase Artifacts
•    Chapter 7—Design & Development
     o System Design Specification
     o System Analysis Methods:
     o Business Process Analysis & Design
     o Object-oriented Analysis & Design
     o Service-oriented Analysis & Design
     o Structured Analysis & Design
     o Data Modeling
     o Design Quality Review Stage Gate
     o Development Cycles
          Kick-off Meeting
          Daily Stand up
          Test-Driven or Test First Development
          The Development Cycle
     o Development & Coding Standards
•    Chapter 8—Pre-Implementation Activities & Artifacts
     o Implementation Plan
     o Detailed Test Plan
     o Training Artifacts
     o Operational Turnover Artifacts
     o Service Level Agreements
     o Change Request
     o Design & Development Phase Artifacts
•    Chapter 9—Quality Assurance & Implementation
     o Quality Assurance vs. Quality Control
     o Quality Models and Standards
     o Defect Classification
          Simple Classification System
          Orthogonal Defect Classification
     o The SDLC Test Battery
     o Verification Readiness Review
     o Release Management
     o Configuration Management
     o Subcontractor Management
     o Multi-Cultural Training
     o Implementation Readiness Review
     o Deployment
     o Operational Readiness Review
•    Chapter 10—Continuous Improvement
     o Embedding Continuous Improvement into and organization
     o Business Transformation Governance
     o W. Edwards Deming on Business Transformation
     o Capability Maturity Model Integration
     o Kaizen
     o Theory of Constraints
          Microsoft TOC Case Study
     o Kanban
          Corbis Kanban Case Study
     o Scrum-ban
     o Statistical Analysis Variants
          Six Sigma
          Lean Six Sigma
          Theory of Constraints Lean Six Sigma
     o IT Performance Measurement
     o SDLC Metrics
          Lifecycle Framework Metrics
               Cost of Quality
               Defects
               Effort
               Requirements
               Size Variance
          Value Chain Metrics
               Knowledge Transfer
               Quality of Service
               Steady State
          Quality Assurance Metrics
•    Chapter 11—Handy Desk Reference
     o The Principles
     o Twenty-four of the most important diagrams and tables
     o Good Requirements Quality Checklist