A Quality Partner's Role in a Senior Management Review

Yesterday, my boss and I had another difference of opinion. He had attended one of the delivery reviews (that's what sr. mgmt reviews are called where I currently work) and was shocked by the quality of the review. He was disappointed at the fact the senior manager did not ask questions pertaining to metrics, did not ask questions on how the plans were created, how effective was the tracking ,etc. He was even more so disappointed at me for not asking the questions myself.
Later after the review he called for a meeting to tell us what our role in the delivery review is supposed to be. He spoke about how the consultants (here we are called Quality Partners) should take charge of the review if the sr. management is not effectively conducting it and gave some wild anologies as usual.
I defended myself by saying that a delivery review is to be conducted by the delivery head and I ask questions that spin off from his where his questions are not rightly answered, or if he does not go deep into the topic. Most of the times, I list out the questions or concerns that I'd like him to look into and hand it over to him before the review to kind of point him in the right direction; and moreover, some senior guys don't like it if you butt into his review, no matter how good a job you do!
Also went on to tell him that all the questions that I have to ask of the project manager, I ask during "my" process reviews. He was not convinced. He said we had to be proactive and bring them on line.
If we are to do the delivery head's job today because he is incompetant, next we'd have to take on the engagement managers' work and then the project managers'. I asked him where do we stop. Instead of eradicting the root problem, we are just fueling it to get worse, because now we are slowly relying lesser and lesser on those seniors' ability to review the health of the project.
Since, he didn't have much to say on that (at least I think so), he said that I am still at fault here because I don't assist the delivery heads by sending them the fortnightly report which is a part of my job. I agreed that I don't send the report, but I do give them a heads up by listing out my concerns for them to address. But that, as per my boss, is not official and formal. So I had to agree again.
Now let's see, my boss, not only wants me to "proactively" do someone else's job, but continue doing what I do at my level. I think to myself, fine let's give this idea a try.
The boss has a talk with the delivery head in the morning today as he was going to conduct a review for another project. He tells the guy that it is my job to ask questions and that at times I will ask questions on his behalf and that he should not take if personally or offensively if I ever supersede him in directing the show.
What the delivery head hears is that it is my responsibility to ask questions in the review and that he can jump in whenever he wants to. He said to me that this is what my boss told him. I know!
Readers, the quality partner, process consultant, quality analyst, whatever he may be called is supposed to be the trusted advisor to the delivery. He is not the person you see standing in front in the meetings. He is the person standing behind the chair and giving information and advice to the person who is actually conducting the meeting. One thing my boss said is right - you must provide the delivery head with data. I completely agree. I also agree, if you live in the world of fear and need to cover your backs, then the communique between the two of you, needs to be official and formal; but nevertheless, whether formal or not, this information needs to reach him before he reviews.
To summarize, the role of the consultant in the senior management review is:

• Give information/status of the project before hand. You may supplement this with risks/issues that you foresee.
• Ask questions if the questions are not deep enough or if the answers are not satisfactory, basically assist in asking questions
  
• Correct him or the audience if their perception on some things is incorrect
• Make notes

But to take over the meeting is a no no! You are setting the wrong precedence and example. You are creating wrong perceptions as to who is in charge and who is affected by the problems of the project. Moreover, don't we always talk of management commitment; well if you are the one talking and questioning, how does one know that the senior management wants to get things done!
Think about it!

Using the Task Usage effectively

My organization recently adopted an Integrated Project Management (IPM) enterprise system. And more recently, underwent an upgrade where the scheduling (using Microsoft Project Schedule) and time entry modules were rolled out.

Naturally, due to the new change that enforced stricter rules for scheduling, the project managers were confounded with the way they were supposed to enter, schedule and allocate tasks in the project plan.

Two days back, a project manager tells me about his problem regarding the issue. His project, which he claimed is different than others (only if I got pennies everytime I heard that) gets a list of defects from the customer on a daily basis. His team is supposed to analyze, fix, verify, validate and deploy the fix for every defect they get. His problem is that the customer is "finicky" about this list and changes the priority of the defects midway, causing his team to drop the current task and take up a new one. His statement was that Microsoft Project was not helping him plan and track his team's activities efficiently and that he'd rather get back to the Excel based tracker that they used earlier.

I have rarely found a situation at work, when we can use the adage "Ignorance is bliss!" and in this project manager's case, the adage definitely did not fit.

Here're the premise of the scheduling he performed and different solutions I gave him:

Premise: Each defect is a single task item or a summary task depending on its complexity. Smaller/simpler defects are entered as a single task, while the more complex defects have sub-tasks such as "Analyze", "Fix", "Review", "Test" and "Check-in" as a milestone task.

If needed, various resources could be allocated to the individual sub-tasks or it could be the same resource. Individual task or sub-tasks are allocated planned effort (work) and the resources are leveled (over-allocations are resolved).

The customer wakes up in the middle of the day and asks that one particular defect be put on hold (defer it) or should be dropped (reject it) and work on any other defect.

Solution 1 - Scenario 1:

If the developer has worked on the defect and/or logged partial time for the amount he's worked for, then while entering time for that defect, he must mark the task as "done". Our IPM system updates the task as complete and logs the actual time against the task in the schedule. For the readers, who update the schedule manually, the process is the same - mark the task as complete and enter the effort (if you record "actual work" in the schedule) put in the task.

If the new defect is in the schedule, well, nothing needs to be done, otherwise, add the defect in the schedule and assign it to the developer (of course keeping the resource leveled).

Solution 1 - Scenario 2:

If work on the defect has not yet started, then simply one can either delete that task (not such a good idea as there would be no simple way of tracking of such a change later) or reduce the "work" for the task to 0hrs and mark the task as complete. That way it does not affect the overall project, except for its dependencies.

Solution 2:

This solution is a little tricky and will require good working knowledge of the Microsoft Project. If you are not confident about making changes to your master plan, make a copy and carry out the steps.

Project allows (as do many other scheduling softwares) the project manager to contour the task. Contour as the word suggests is the shape of the outline/surface of the object, in this case the object is a histogram of the work spent on the task each day. See the image below (not created in MS Project).

 

The top border (or the surface) of the histogram defines its contour, but I'm sure you figured it out already.

So, MS Project allows the following contours for each task:

1. Flat - Effort equally distributed
2. Back Loaded - Amount of effort gradually increases as the days go by
3. Front Loaded - Amount of effort gradually decreases as the days go by
4. Double Peak - The effort peaks twice during the life of the task
5. Early Peak - More effort is expended early on and then the amount stabilizes as the days go by
6. Late Peak - The effort is stable early on and then peaks towards the end of the task
7. Bell - This, if it is not wrong for me to call it so, can be termed as "Middle Peak"
8. Turtle - This is similar to the 'Bell' contour with the difference being that increase (during the early days) and decrease (during the later days) in effort is gradual and does not show peaks. Very similar to a turtle's back.

Selecting one of these contours will distribute the effort of the task as required in a ratio that Project calculates for you.

This can be done in the 'Task Usage' view (click on 'View' in the menu and then click on 'Task Usage'). Identify the task that you wish to work on, expand it (by clicking on the '+' sign next to it) to reveal the resource(s) assigned that task. Select and right-click on the resource(s) and select 'Assignment Information' option to see a dialog such as the one below.

 

It is on this dialog you will see the drop-down for Work Contour. Select one and proceed.

If you don't like the distribution the Project has set for the task, you are free to change the effort planned for each day in the pane on the right. In which case the indicator next to the resources will show icons like the following, indicating a custom contour.

 

So, if the task is put on hold for a definite duration, change the contour or task usage to reduce the effort spent on that task for those days to a minimum or zero.

This way, you don't lose track of the tasks nor do the resources have to enter time against (or work) on those tasks for the period of lull.

Should we SCRUM?

It is that time in the life of this industry when something new has passed the horizon and is approaching us at top speeds. Later in the last century, it was CMM, followed by CMMi in the early years of this one. This era of evolution sees the dawn of Agile practices.

Agile practices have been around for over a decade now. The industry just took it’s time shifting gears around it, slowly and steadily now advancing towards top gear.

We are all aware of what Agile practices in software development means, perhaps in its entirety as the authors of these practices intended it to be, or in some corrupt deviant phenomenon. We, as the flock of IT industry, believe this is the silver bullet that will release us from the clutches of software development hell. We also believe this one to be more silvery than its predecessors.

But remember this; this is exactly what the creators of this so-called weapon say it is not. There is not one piece of literature that states that Agile practices (in whatever form) are silver bullets that can magically kill all evils and make your life better.

SCRUM is one methodology that is based on the Agile philosophy. SCRUM, as I see it, is an excellent framework to improve overall project’s performance and provides good practices for Agile Project Management. It talks of well defined roles, limited number of artifacts (for project management and not as a part of the technical package of the project), and clear and concise rules on how each iteration needs to be executed.

It is not difficult to understand SCRUM. It would take less than hour to give a novice enough insight on SCRUM, to enable him/her to understand all its concepts. The difficult part, as with anything else in the world, is implementing it. And moreover, implementing it in services based IT companies.

While I evangelize SCRUM from the deepest corners of my heart, I have to but point out the fallacies of force-fitting SCRUM in places where it is not welcome.

Before we continue, let me lay down in front of you the scenario that I am considering while presenting the counter arguments of the implementing SCRUM in IT services industry.

“An organization, ABC Limited, is dedicated to providing IT solutions to its customers. The organization has many clients across the globe and is making/or has made its presence in the world of highly competitive market of providing services. It is a vision of this company to increase its size by another couple of thousand by then end of Financial Year 2009. It also aims to increase its revenues by 15% year over year for the next five years. The space that it operates in is also occupied by the top IT giants of India and hence has everyone fighting for the same piece of the pie.

“As with CMM and CMMi of yesteryears, the company now faces the demand from the western world to deliver their services in a SCRUM fashion. CxOs of client companies all across the globe have attended at least one conference in the past three years that showcased successful products that were developed in an SCRUM environment. Over the next couple of months, the CxO asks his/her executives to research and provide him/her with details of SCRUM framework and its benefits. The executives attended more seminars that evangelized SCRUM and came to a conclusive report that the organization must ask its vendor ABC Limited to adopt SCRUM.

“As with any wild eco-system, where “survival of the fittest” and “evolution by natural selection” are the ground rules to survival, IT companies, specifically, ABC Limited, changes it processes to incorporate SCRUM’s practices.

“Taking a more optimistic picture, the company ABC Limited, spends valuable resources, to dig deep and clean and modify its processes from the roots, rather than just batch renaming their processes to “agile”-processes. Come launch day, a brand new project (of a customer that demanded SCRUM) is asked to pilot it.

“The project team is trained in the specific workings of SCRUM. They are told:

1. Thou shalt not change thy commitment during the Sprint
2. Thou shalt have Daily Scrums for the team members to update each other on progress and impediments
3. Thou shalt have a ScrumMaster, who shall not manage, but facilitate
4. Thy Product Owner will not interfere on a daily basis (micro-management)
5. Thee and only thee is responsible for estimating and taking ownership of tasks and deliverables
   

“When the project starts the worker ants get busy. All motivated by and enthusiastic of this new framework, they are confident that they will be able to achieve all their targets. All is well until, the customer calls to change a specification and the team is asked to accommodate the urgent request in the Sprint. Next week comes, and the customer has more changes. Slowly, by the last sprint, changes are common, re-work is high and the team’s confidence on SCRUM is low.

“In the meantime, the project manager in his new avatar as the ScrumMaster has been trying to manage and control the team throughout the execution of the project. He ends up estimating and assigning tasks to the team. The Product Owner starts demanding daily status reports on the progress of the team which now becomes the main agenda of the Daily Scrums.

“In time the project fails to meet its desired state and the customer blames the team, who in turn blame SCRUM.”

This is not an out-of-the-blue case study. It is pretty much the fact across all organizations that claim to be Agile but in all practical sense, are not.

Adopting agile practices, in this case SCRUM’s practices, is not about adopting only what is felt beneficial, but all the practices as a whole. It is a package deal. It is not about just renaming processes to hoodwink customers into believing otherwise.

Neither customers nor the teams working on projects are at a liberty to discard or adopt practices as they feel fit.

Adopting SCRUM has a lot of advantages – both for the team as well as the customer. But for it to be successful, it needs to be understood completely by both parties.

Both parties need to understand their respective responsibilities in this game called SCRUM. Customers need to understand that micro-managing, asking for daily status updates and changing requirements on the fly is NOT allowed. Project teams need to understand the severity of their commitments to Sprints. And it is a Catch-22 situation.

Customers do not have confidence in commitments of project teams to go blind for the length of the Sprint and hence feel the need to micro-manage. Since, the project team no longer self-manages itself and the Sprint, the commitment they make is no longer strong.

So, this brings up the most obvious question in our minds. Where can true SCRUM practices be implemented? My most unintelligent guess would be – the Product companies. The teams (including all the way to the VP of the product) in such companies have more control over the features, technology and the execution process than typical service companies. While they still have market pressures, the buck still stops within the organization and that makes all the difference.

To support my argument, I have not come across any presentation or article that has a list of service companies in the list of top users of SCRUM. It may however list a part of the service company that is considered to be, not a vendor or a partner, but an extended arm of the customer’s development team itself. In that case, there is not too much of a difference between the customer and the offshore development center of a vendor that it controls.

Bottom line

For the apparent business reason, it is very difficult for a service company to say ‘No’ to its customers. It is even a bigger challenge to ask them to hold on to the change requests till the end of the sprint. And unless the customers are themselves geared up to speed, this golden rule of SCRUM will inadvertently be broken.

And this is the real reason why SCRUM cannot be implemented in IT services companies; at least not without making real changes in processes of both the vendor and the customer. And until someone comes up with a model that suits this kind of multi-location contract based development, I’d recommend not forcing SCRUM down our own throats and make it another CMMi-like fad.