Mark Gibson; PgMP, PMP, IBM certified Executive Project Manager

Have multiple releases?: A different approach to maintaining the branches.

Have you been in a operational environment where multiple development streams each with unique functionality are in development but the release to production dates are not in a definitive sequence.  Or perhaps, an incremental release development model where the development is broken into blocks that are larger than any sprint/iteration.  These are examples of the scenarios whereby the question of when to merge the development in the configuration management tool branch becomes an acute question.  The timing of the merge to the trunk places the operations or project manager in a position whereby the production environment cannot be updated until the new functionality is also deployed.  This becomes an increasingly acute problem when the number of changes in production is higher, of high priority, or the size of the new functional release increases as the regression test cycle is necessarily longer.  So how do we solve this problem?

Traditionally, we have merged the branches to the trunk and built our pre production testing environment from the trunk which creates the circumstances noted above.  I suggest reversing that model.

As changes are made in the trunk (production) merge those changes out to the branch(s).  This creates in the branch(s) a code baseline that is identical to the future production environment and relieves the need to know definitively the order in which the branch(s) will be deployed to production.  It also creates in the branch a code baseline that is identical to the future production state but is in the branch and not the trunk so the capability to update production with either high priority fixes or any other branch remains.  In this instance, the issues associated with merging of the new functionality to the production baseline are flushed out in the branch by building the pre-production testing environments from the branch and testing. 

Once the functionality is flushed out in the branch and this branch is determined to be the next going to production, then the branch is merged to the trunk, regression testing and release to production occur.  By testing out in the branch, the regression testing from the trunk (after the merge) is greatly reduced thus minimising the risk of production maintenance during the regression testing window.  The positive side effect is the decision on which new functional release will go to production is delayed until after the functional testing in the branch and easing any decisions in this area.

The downside to this approach is more maintenance of code out in the branches.  The decision becomes a trade-off between the risks associated with longer regression test cycles and the inability to maintain production during this cycle with the additional effort associated with maintaining the branches.  In those circumstances where there are a lot of high priority updates in production and/or the new releases are large, numerous, or have long regression test cycles, I suggest considering this alternative approach.

Leadership Question: Does the PM work for the resources?

This is a fundamental question that on the surface has the obvious answer of the resources work for the PM. Is this true or really a matter of leadership style.  Having a background as an officer in the US Navy, I learned long ago that the leader who takes care of his people is the leader whose people take care of him/her.  I would propose that the PM works for the resources. 

In my opinion, good Project Managers are good leaders and good leaders spend a significant part of their day on several activities:

1. Risk Management (clearing issues that will restrict the team’s capability to function freely)
2. Solving organizational issues such as the team makeup and tasking for resources
3. Working with external organizations who support the project like a customer support organization who fixes commercial product issues
4. Negotiating with the customer for resources, tools, and environments (DEV, TEST, etc)
5. Prioritizing the work when conflicts occur

In each of these instances, this work is in support of the technical resources working on the project.  In other terms, the PM is working to make the work environment easier, clearing resource constraints, or helping prioritize work for the project resources.  By working for the resources in this manner, the PM gets in return:

1. A more efficient work force
2. A happier workforce
3. Less downtime while external factors impact the project schedule

At a practical level, I try and address my team’s needs first and once their needs are met, then I can start my day.  In many instances, my day does not begin until dark but the project moves forward efficiently. By prioritizing the needs of the team first, the PM also builds a level of respect, rapport, and confidence from the team that will be needed if the project gets into a situation where additional time or effort is needed to reach a milestone.

By viewing their role and leading the project team in this fashion, the PM will reap significantly more benefits than viewing the resources as working for the PM.

Time and Materials Budgets: Who is responsible?

In my experience, project managers view Time and Materials Budgets in two separate ways: 1) the customer is responsible for containing the budget through scope, 2) the project manager assists the customer in maintaining both the labor and expense budgets.  Individuals are very passionate on either side of these schools of thought.  How many times have we heard, "It's time and materials, let the customer tell us what they want." or "It's time and materials, we will reassess budget after the requirements are complete."  Each of these statements assumes a non-agile model which is a separate discussion, but in my opinion is something the PM should reconsider.

In the first school, PMs proceed through the requirements processes and allow the customer to define the requirements without regard to cost containment.  In most instances, the end user community of the customer shoots for the stars and asks for more than they really need.  In some cases, they know the scope will be reduced and in others see how far they can push the vendor.  This leads to a situation whereby the available project budget has been exceeded, customer expectations are high, and the PM has to reduce the scope of the project to maintain a budget somewhere near the original because the end users do not have a mechanism to understand the cost of their requests.  An additional problem with this approach is an implicit assumption that the customer can afford any set of scope or that the customer is responsible for containing the aspirations of their end user community.  I find this to be true in only a small number of cases.  Taking this position can put the customer PM in an awkward position.

Given the customer technical resources must work with their end users over many years, they implicitly look to the vendor PM to maintain the scope within the budget as the requirements unfold.  This affords them the opportunity to be the arbitrator of any disputes and keeps them in a good long term position with their end users as they are perceived as looking out for the best interests of their users.  This school of thought also entails the vendor PM to identify and maintain a tally of the extra work the customer is asking for that is producing upward pressure on the budget.  By keeping the top end number in front of the end users, the customer PM can maintain a more appropriate arbitrator position while still maintaining the high level budget figure.  This also puts the responsibility for cost containment on the vendor PM as they will need to dynamically maintain a running budget figure while keeping a viable solution in place.  Typically this includes updating the customer PM on the cost of the emerging scope through a series of estimates.

In the end, responsibility for budget control is shared between both PMs on the project.  For vendor PMs who take the lead in containment with the customer, they will have a better positioned customer PM and a better relationship.

Analyze or Gather Requirements.. What's the difference?

For many project managers, these terms are synonymous and entail those activities in certain models that occur at the outset of the project whereby our project teams write a requirements specification.  Personally, I am not a big advocate of documentation heavy implementation models but understand these models remain prevalent in today’s projects.  So what is the difference between gathering and analyzing requirements?

In my opinion, gathering entails that set of activities whereby customers are asked to define their requirements including that set of needed capabilities, interfaces to existing systems, reports, etc.  In a nutshell, the project team is told the set.  When analyzing requirements, the project team listens to how the customer runs their business before distilling the conversation into a set of business needs.  In a nutshell, the project team analyzes the business operations and defines the requirements vice being told (gathering) the requirements.

Clearly in either situation, the customer will ultimately agree upon these requirements so neither activity is not completed in isolation. Typically, what I have found is many business users if asked to define their requirements will actually tell the project team how their current system works.  How many times have we heard the phrase, "my current system works this way", or "this is how I do it today."  What the users typically describes is that set of key strokes or data entry that occurs within the current system.  This approach will necessarily include how screens function, what reports are required and is not necessarily what the new system capabilities should be but what the old system does.  Especially with a commercial software implementation, gathering requirements sets the customer expectation the new system will work like the old system.  This leads to extensive customization of the commercial software, force fitting business processes vice optimizing them and rarely leads to a new system that is an improvement on the old system (the reason for the project).

In the situation whereby, the project team analyzes the requirements, the old system context is not set as an expectation but rather that some business processes will change and will improve the business situation.  When the customer leads with "My current system work this way," the project team should probe deeper and ask the why questions to understand the true business requirement/need.  This affords the project team the opportunity to model the business processes within the core capability of the commercial package, minimize customization, and ensure the strategic objectives of the project are met the most important of which is an improved business situation with the new system.

To illustrate the point, I recently had a customer who during the requirements phase was defining the required data elements for a screen including screen operation.  They were describing how their current system operated.  The system was a service ticketing system that required a screen to input service tickets, another to modify tickets, a third to review tickets resolutions, and they needed three reports to manage the business.  Clearly, they were defining a detailed design based on the existing system.  To distill the requirements, I asked a couple of pointed questions.

Why do you need a screen to analyze tickets?

Why do you need a separate screen to modify tickets?

What are the purpose of the three reports?

By asking these questions, I determined the customer uses an outside vendor to service the tickets and this vendor is paid for each resolved ticket.  The three reports were currently used to support the invoice review process and were three different cuts of the same data.  In this situation, the project team now understands the business to a deeper level and has greater flexibility in not only improving the business but providing a solution with minimal customization.  In my instance, I combined all the screens together as this is how the commercial package works and provided a single report in the form of a pivot table that provided the customer an easier way to review invoices as well as an electronic record of the reconciliation process which eased the negotiation process when differences of opinion occurred.

In my opinion, project teams and especially commercial software project teams should always analyze the requirements vice just gathering them.