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

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.

Do we need a stabilization period?

Over time the concept of a post go-live stabilization period has emerged.  For many companies, this is a period of time after deploying a new major release to production where previously unknown issues are identified and rectified.  Additionally, end users spend a period of time becoming proficient in the new release and eventually become comfortable as both the technology matures and their knowledge and comfort levels stabilize.

These periods have become the norm since "it just seems to work out that way."  As we project managers have deployed a few net new implementations or major releases, it seems this period is inevitable.  The project teams have done their due dilligence in design, building, and testing but inveritably there are issues either technical or functional that are always found after the deployment.  We have done our best and "it is what it is."  We find a previously unseen path in a business process or an additional value in a status dropdown menu.  Perhaps, we also identify an end user who needs additional training in the execution of a particular business process.  It could even be an overnight batch job that runs longer on the last Sunday of the month due to other software jobs running at the same time causing operational issues.

This leads us to a fundamental question.  Are stabilization periods merely an inevitable part of a software deployment or are they indicators that we project managers have areas of our planning and risk assessments on which we could improve?  As touched on above, the stabilization can occur in either technology or functional areas or both.  Let's examine some ideas on how to reduce or eliminate the need for a stabilization period.

As project managers, one of our fundamental tasks is to assess risk, manage risk, and build project plans that minimize the risk profile.  Below are a series of thoughts and concepts to minimize these risks and improve our project plans with the intent of minimizing or even eliminating the need for a stabilization period. 

The first set of ideas takes the concept of a BETA testing period and moves it to the left.  With BETA testing, project managers will typically deploy the solution to a small subset of users and enable them to operate the solution under true production conditions.  These conditions use production data, real life business processes, address real life scenarios including all edge cases, as well as address user interface design and ease of use.

Free Form User Acceptance Testing

In most projects, we will define a set of test cases for testers to execute.  We measure the completion percentages, define exit criteria for completion of the test phase, and base our completion decisions on quantitative data.  These are all good things as they provide us a firm factual basis for making our deployment decisions.  These techniques are a fundamental part of our projects and should remain so.  What I am advocating is an extension beyond traditional UAT.  The issues arise when we assume our use cases or test cases represent 100% of the scenarios the solution is designed to address.  Although this is the goal, most project teams find this a very difficult task to achieve.  Even with dedicated test teams, the task is challenging.

In a BETA testing period or stabilization period, the testers are free to execute any business process, address any scenario, and use any set of keystrokes imaginable.  This is truly representative of the production environment since the users will not have defined keystrokes to address every production scenario.  What would happen if we defined a second phase of the UAT to be a free form period?  We could encourage the testers to execute their daily work since it is this work where the edge cases will be identified.  Given the scenarios are randomized, the testers also get the added benefit of getting beyond scripts and are required to truly understand the software and become proficient with it but in an environment and timing that does not impact production work.

Effectively, what this does is move the "stabilization period" back into the project where we can plan and monitor its progress.  The number and severity of errors will become known over time so the duration of this second phase can be difficult to pre plan.  The advantage to this technique is we uncover and repair any errors in a test environment and not in a production environment where the business impact is much greater.

Run batch jobs in production once confirmed functional

In projects that are net new implementations, we can extend this same concept to any interfaces we build.  The main issues with new interfaces are typically three fold: 1) interaction with other batch processes, 2) data moving from one system to another, and 3) target system functioning properly with data from source system.

During the course of our projects, we will build interfaces that both maintain lookup data like products in a eCommerce solution or transactional data like leads sources in a CRM solution.  In each of these instances, unforeseen edge cases can arise and we would like to catch and repair issues associated with these cases.  So let's move this identification process to the left and back within the product schedule where we can better manage the uncertainty.

As the interfaces are built, turn them on and let them run.  If the eCommerce solution has a daily update of products from a PLM solution, turn it on and let it run each night.  Over the course of the rest of the development, this interface will run enabling both the technicians monitoring the interface to become accustomed to it running, will catch any errors resulting from edge cases enabling the project team to fix them, and will identify any unusual run times and make the needed adjustments. All of this is done before the solution is in production enabling the project manager the time to appropriately plan and schedule the repair activities.

For interfaces such as lead generation and especially in cases where manual steps like pointing to a lead file are required, the administrators and even the end users have more opportunties to become proficient in the mechanics of uploading the file for example so are more proficient long before the solution goes to production.

The above concepts are driven by moving the stabilization activities to the left back into the project.  The next three concepts address how we can improve the identification of those cases normally found by free form testing and ideally identify them in the early stages.  Even with the techniques above, the project manager must address unforeseen development activities that can impact the project timeline.  Identifying these cases during the planning cycles enables a more complete project plan.

Testing that simulates real world

Since we started the examination of concepts beginning with production and working back to the project beginning, let's continue this approach and address the formal test phases.  What can we do here to improve our testing.

The fundamental premise of testing is to create or recreate the production scenarios so our project teams can identify and repair the issues eventually leading to the satisfaction of all business requirements or use cases.  This remains a good objective but we can augment that objective by examining how we both structure the test cases and execute them in the context that more closely resembles the actual production environment.

Let's look at an example of a solution for financials.  In this example, the solution includes a wide variety of business modules including Accounts Payable, Accounts Receivable, General Ledger, Billing, and Purchasing.  In examining these modules as a set, they have a monthly rhythm as companies close the books monthly and define financial reports on a monthly basis that roll up into quarterly reports.  If a public company, the quarterly reporting includes SEC reporting.  Quarterly reports roll up into annual reports.

Could we structure the testing of a system like this to simulate a years worth of activity?  The test period itself would be much smaller than a year but we could define a month as a week of testing.  So week 1 of testing would translate into the first production month.  Close the books on Friday and start the second month at the beginning of the next week.  This would enable the test team to execute all the test cases associated with purchasing materials, receive the invoice, perform all required matching, cut the check from AP, then post the journals to GL and close the books at the end of the month.  The same concept applies to the invoicing and AR side.  Some purchases or invoices would remain in AP or AR until the next month as would naturally occur in production.

With this same technique, the quarterly reports and SEC filings could be executed and eventually annual reports.  Having this in context both exercises the system through an entire year but also assists the end users in thinking through all aspects of the process as it is not within the context of software requirements but in the context of their every day jobs of which they are far more familiar.

Naturally as the issues are identified, the project team would prioritize and repair them.  By structuring the testing within a more functional context, the project manager can achieve a production simulation that more closely represents what would happen during the "stabilization" period.

Can we also test the beginning of the business process first?  For example, lead generation and processing begins with the generation or loading of leads before proceeding to lead assignment, then working the leads and creating opportunities, etc.  If we flush out the lead generation functionality first as each subsequent sub process like lead assignment is developed we will naturally test the lead generation then lead assignment.  The software will dictate we add leads before we assign them so the initial sub processes are continually regression tested as each sub process in the entire business process is added.  Combine this will using production data and we are now continually regression testing previous builds, verifying edge cases by using production data, and minimizing the defect detection risks inherent in formal testing.

This leads us to the last two concepts which stem from how can we improve the initial set of test cases.

Business process flows that lead to use cases

The key to better test cases in my experience is getting two sets of people involved at the outset of the project.  The first is actual users of the system.  Typically, our project teams will ask the business users for their requirements or use cases and anticipate the resulting list of items will be complete and accurate.  In my experience, this is a difficult question for a business user to answer because it is not within a context the business user typically works and thinks.

If we ask the question in the context of the business user, we can anticipate a better and more complete response.  I like the use of business process flows as a predecessor to use and test cases.  We ask the business user what activities do they perform on a typical day. Yesterday can be a great start or what did you do last week.  It starts with the day to day activities and moves into the more unusual cases that we would call edge cases.  Document the activities within a business process flow as this both defines a good mechanism to extract use cases but also provides a mechanism for defining alternate flows and negative cases.

When we reach a decision point, there must be a yes and no patch.  Remembering to come back to the less traveled path may be difficult but stands out in a process flow.  It also spurs us to ask the question "what if that does not occur." The business process flows enable our project teams to be more systematic in our investigation and documentation of the requirements.  By being systematic, we can collect a higher percentage of the actual cases that will be observed in production.

Testers involved in defining edge and negative cases

As a supplement to this process and if a dedicated test team is available, these individuals should be involved from the beginning of the process.  Testers by nature tend to be detailed people who are adept at finding both the edge and negative cases.  Dedicated test teams also tend to have good relationships with the business users so they will feed off each other as they collectively think through how the business operates.  Both of these dynamics are positive for the project manager as the end result is a more complete and detailed set of use cases or requirements from which the plan is planned.

If we follow stricter and more structured quality assurance and testing techniques, the length of stabilization periods become far less than previously experienced and may even become negligible. Thinking through the reasons for stabilization periods and structuring our project plans to minimize these risks enables project managers to have smoother running projects and minimize or eliminate the need for stabilization periods.

Prototypes: The resource skills needed to execute

When it comes to IT projects, some people have the vision, others the handi-work, and still others the skills to bring them together.  The project is the path to make that vision a reality.  Prototyping is a great tool to speed the project along with accuracy, success, and ultimately to client satisfaction.

In the 90's, the 4th generation languages made their entrance into the software development world.  This enabled developers to work side by side with business people to prototype screens.  In real time, business people would investigate different page layouts, graphic designs, and could envision business scenario execution with the evolving screen.  This was an enormous productivity tool as it enabled project managers to turn around revisions of screens in minutes instead of hours resulting in shorter development timelines, solutions that met business needs to a higher degree, and happier customers.

With the advent of integrated development environments (IDEs) for both software applications and suites of applications like Salesforce and BigMachines, the concept of prototyping has extended into complete business functions.  With BigMachines for example, consultants can prototype the entire quoting process including product configuration, rules and bills of materials, or pricing and even reports in Document Engine.  In Salesforce for example, consultants can prototype sales or services processes, sharing rules for accounts or opportunities.  Essentially, consultants can now prototype any business process extending the value of shorter development time, better solutions, and happier end customers to nearly all aspects of an implementation.  This results in shorter implementation times at lower cost, higher returns on investment (ROI), and more value to the business.  In the current era with broadband internet connections, and using tools such as GoToMeeting or Webex, this prototyping technique is also leveraged for virtual teams.

In order to accomplish this, the resources working with the business need a special set of skills including:

• Real time understanding of the business scenario or issue
• Real time ideas on how to solve the business scenario or issue
• Deep understanding on the commercial software product and how to configure the product to solve the business scenario
• Patience and poise to work through multiple different scenarios as business people investigate different options, weigh the pros and cons of each option, and determine the optimal solution
• Project Managers able to leverage this technique while maintaining project budget and schedule constraints

This rare blend of business expertise, technical prowess, patience, and management skills is difficult to find in an organization but very valuable once found and put to use.  So, it's not the prototype itself, that achieves client satisfaction, but the successful execution of the project using prototypes that achieves this ultimate goal.

Relationships between use cases and requirements

In some organizations, the terms use case and requirements are used interchangeably.  In some respects this is an understandable point as both are ways to define the basic functions that software must accommodate.  They are both typically defined early in the project, are used as a basis for estimating the effort involved in a project, are grouped so developers or implementation consultants have some structure during the development or implementation phase of the project, and they are also used as the basis for testing planning and completion.  In many ways, they are similar.  In terms of usefulness for test case and training material development, they are very different.

At the outset of any project, we project managers look to gain insight into what the solution must do.  In many cases, we ask our business users what they would like the new software solution to do for them and we call this list of items, requirements.  This approach is well seasoned and has manifested itself in techniques like Joint Application Design (JAD) sessions where groups of business get together and discuss their needs of the new solution.  Project team members furiously take notes as the items are identified.  Even though this is a well seasoned approach for developing requirements, it is difficult question for business users to answer because they do not think of their business in this manner.

In my experience, business people are well versed in how the business is conducted, what they do on a day to day basis and what information and in what format they need this information to be effective in their varied positions within any company.  This business context is a key differentiator between use cases and requirements.

When developing use cases, the project manager asks the business team what they do on a day to day basis, what they do on rare occasions, and finally what they do on a very intermittent basis.  These questions have the context of the business activities they perform.  In order to be complete, project managers can start with more senior executives or even the project sponsors to get an idea of the breadth of individuals from whom to solicit their day to day activities.  These are the use cases.  A similar interviewing process can occur with individuals but with much smaller groups so each group can focus on their area of responsibility.  The project team can collect the use cases from each team and consolidate them.

By collecting from each group, a natural organization occurs since each group is typically a functional group enabling the project manager to begin to organize the use cases and therefore the development or implementation activities into a structure well known to the people who will both be served by the new solution but who also are likely to determine when the solution is ready to deploy.

Besides functional business people, a prudent project manager will also interview technical staff who will both administer the solution, network, interfaces, and batch processing.  These technical use cases are equally as important as the functional ones.

When defining requirements, an interview is typically the well traveled path to definition.  Many services companies have defined templates or questionnaires to assist with getting a complete set of requirements.  All of these approaches prove difficult as each software solution is unique to the customer.  We typically find our requirements sets of incomplete and this realization does not occur until deep into the testing cycles or even as late as the first few days after going live.  As consultants, we are very conscientious about doing a good job but we are behind the eight ball.

A natural mechanism for developing use cases is to start with business process flows.  Business process re-engineering (BPR) was very popular in the late 90's as companies began to look critically at their internal operation.  On many occasions as part of an Enterprise Resource Planning (ERP) implementation, my project teams would start with the business processes, take the opportunity to identify areas of streamlining since the process data was consolidated and became easier to identify these areas.  Although BPR is less popular today, the definition of business processes can be a good starting point for use case definition as the use cases are each unique path through the business processes.

In previous posts, I have mentioned the advantages of process flow diagrams as they identify new paths that are not always apparent and provide a mechanism for being more systematic in the approach to define use cases.  My best projects have started with using process flows as the starting point for use case definition and then leveraging these use cases further down the line when writing test cases and even training material

Once the project manager has a good set of use cases including the happy and non happy paths through the business processes, these same paths become the basis for the test cases.  The difference with test cases is a test case should address each inflection point within the continuum of data that could pass through the use case.  For example, we may look at closing the AP books for the month.  The use cases will be the same but the test cases include open AP across the boundary as well as open and closed within the month.  This different data condition may lead to different handling within the solution.  Another example could be a calculation algorithm whereby negative numbers are not permitted such as in a financial example or were a zero is handled differently. All could be the same use case but different test cases so the unique data conditions are exercised.

Finally, the use cases can be the basis for the training material.  Given the use cases define all the business activities needed for a good solution, the end users will need to understand the keystrokes to perform each of these business activities within the solution.  At a high level, the trainers can take a representative set of test cases including the organization defined during the collection process and build training material off this set.  The unique activities are defined within a structure that makes sense to the business and is broken down into functional sets that align to the set of users to be trained.  What is remaining for the trainers is to capture screen shots where appropriate, define exercises and pre-stage data into a training environment if so inclined.

Although requirements and use cases are perceived by many organizations to be very similar or synonymous terms, the manner and context in which they are derived as well as the additional value of use cases in the testing and training realms define some separation between the two.

Planning for the unplanned

Planning for the unplanned sounds like a contradiction.  How can you plan for an unknown?  It seems like the definition of unplanned.  In some ways this is true in that project managers do not always known the difficulties we will face on a project.  Risk assessment and management goes a long way when we can be predictive about these potential unknowns or use our experience to identify potential future obstacles.  All of these techniques remain germane and prudent.

At the end of the day, there is nearly always some obstacle that arises on a project that comes out of left field on us. Maybe it is an unforeseen illness of a critical resource or proven technology that is incompatible with the current environment, or even an external obstacle like another project needing a planned human or technical resource.  I like to say there is going to be something we just do not yet know what it is.  So we are back to the original question of how to plan for that which is unplanned?

Cross train all staff to increase flexibility in task assignments

In a typical project team, each individual has their role and even individual staff may have specialities.  This single threading on technical or functional capabilities can work well especially early in the project where multiple tasks are available on which each individual resource can work.  Later in the project and especially during the formal testing periods, the project manager cannot pre-plan or anticipate where the issues will be and what the level of effort will be in any individual functional or technical area.  Given the unknown effort of an unknown number of issues in unknown areas, the project manager can best prepare for this situation by cross training the staff across functional and technical areas.  Ideally, each individual should be able to work in each area but this is not typically possible.  The best the project manager can hope for is to maximize the cross training possible.  With each area where multiple resources can work, the project manager is best positioned to react to the unplanned situation when it occurs.

Front load any tasks with float and prototype when possible

In our project plans, we will inevitably have tasks with float.  This float provides the project manager flexibility to determine the timing of when to accomplish these tasks.  When combined with the cross training above, front loading the tasks with float provides the project manager an option to add staff to critical path activities or start a critical path activity early and parallel it with its predecessor to some degree as a mechanism to decrease duration and recovery some schedule.  Early completion of float tasks frees the assigned resources to perform unplanned tasks.

Front load any highly technical or risky tasks

With any project, the project manager will identify those tasks with the most risk.  High risk tasks are one of the largest sources of unplanned tasks.  The high risk can come from uncertainty in the technical solution.  With this uncertainty comes the possibility of unplanned work when the original thoughts on design or implementation prove untenable.  By front loading these tasks earlier in the project, the project manager affords themselves a longer period of time to replan and recover.

Leave architect time for utility infielder tasks

In previous posts, I have described the concept of a project resource who can work across any functional or technical area and has the depth of knowledge to work on any task where it be a strategic task or a very tactical development or implementation task.  When possible, capacity with this type of resource also affords the project manager some flexibility when unplanned tasks do occur.  By having a resource with a wide skill set, the project manager can initially staff this resource on the unplanned task which provides stability to the efforts of other staff.  Maintaining stable resources on tasks until completion is well known to be effective in maintaining planned durations and higher quality output of planned tasks.

In a nutshell, planning for the unplanned is about producing a solid project plan with minimal risk then monitoring and controling task completion to maximize available capacity within the team.  By cross training, it provides the project manager greater flexibility when reacting to unplanned work.  Having the senior resource with extra capacity not only enables assistance to be provided to more junior staff but enables the project manager to assign a senior resource the unplanned task so to minimize any negative impacts that may result.

Is Documentation a critical component of the project?

With the initial development models like waterfall, documentation was a critical component of the project to both define and manage scope, gain agreement on design, and eventually determine if the solution met the requirements through the testing phases.  We as project managers used documentation as the vehicle to gain alignment with the community who needed the solution.  This trend has continued with the introduction of commercial software who provide a shell into which implementation teams enter meta data to tailor the commercial software to the unique needs of the customer.  Even today, with the introduction of web applications leverage Software as a Service (SaaS) or cloud-based offerings, documentation is a common component.

Documentation remains a good mechanism for recording how commercial software was implemented; the meta data entered to tailor the solution.  For the worst disaster recovery scenarios where the solution must be rebuilt, this documentation is the foundation upon which disaster recovery plans can be built.  Documentation of test cases and the test management controls associated with a firm set of test cases enable project managers to track testing progress and answer the two main questions: Are we on schedule? and when will we be complete?

As SaaS and cloud computing become more popular, these vendors maintain multiple backups of the environments and offer embedded disaster recovery not before seen with on-premise implementations. The worst disaster recovery scenarios noted above are not as relevant as before since the vendor is covering off on this conditions.  Furthermore, many of the vendors such as Salesforce and BigMachines offers integrated development environments (IDEs) with the cloud-based offerings so the documentation of designs and code can occur within the IDE and be backed up using the same mechanisms as the transactional data.  Even with on-premise implemenations, nightly backup can occur to simulate the same offering of the SaaS or cloud-based offerings.

Looking even further back into the development processes and considering the newer agile and prototyping methods of development, we can begin to question if detailed designs and even traditional requirements are a necessary and critical component of a project in today's world.  With these methods, the detailed design evolves as the users gain experience with the solution, exercise their business processes within that solution, and fine tune the design.  With the agile models, defining the contents of each sprint continues to make sense as this information is not typically captured otherwise and project teams can utilize the multitude of agile management tools like Version One to streamline the documentation efforts. At this point, some people may be claiming heresy as this discussion is questioning the well seasoned methods of scope definition and control.  To some degree I agree as eliminating all documentation does not make sense to me.  Can we critically look at the volume of documentation we perceive is needed and look to repurpose this capacity to delivering additional functionality to our customers?

For example, when two disparate groups are working on a common solution such as with an interface, then a interface design may make sense.  This can especially be true when working with two groups each with their own contract.  In order to confirm proper contract execution, the definition of the work through an interface design makes sense.  If we look at the same example and remove the contract constraint, the need for an interface design document may be different.

Even the documentation of code or an architecture could be questioned within this same context.  If we adopt the newer agile methodologies and do not have contractual constraints that drive the need for documents, do we really need documents on our projects?  Historically, these documents have been a mechanism to reach agreements but if we use close coordination such as what can be achieved with a scrum meeting or other frequent coordination forum, projects today can drastically reduce the need for documents and free up this capacity to build more functionality.

As we look at the risk profiles on our projects and build our project plans, we can and should consider when formal documentation is needed, when we can achieve tighter coordination through more frequent face to face (includes electronic through Webex or GoTo Meeting like products), and focus more energy on building more functionality for our customers.

Pricing based on effort or duration

As a precursor to consulting engagements, project managers are commonly asked to price their projects.  But how does one go about pricing a consulting engagement?  A common method of pricing is to collect a set of requirements or use cases and collaborate with the individuals who will perform the work.  From this collaboration comes an estimated time per requirement or use case.  All of this is a good starting point for pricing.

 

Typically, the next step is to add up all the hours, multiply by the rate(s) of the resources and calculate a price figure.  The calculations become more complicated if there are multiple rates, time for testing, project management, and perhaps start up time are added, but one key point, I believe, is missing with this approach.

 

As project managers, we have all developed a project plan complete with our work breakdown structure (WBS), resources, and dependencies.  It is these dependencies and the resulting float or slack that drives the fundamental question for this post.  The above approach to pricing implicitly assumes that each resource is utilized 100%, a logical assumption and goal.  But we all know that each project has some float/slack in it so all resources spend some time outside of the effort defined in the estimates and are, therefore, not utilized 100%.  This additional time consumes budget and rightfully so.  The concept of the PERT chart was developed to both highlight and calculate this float. 

 

This is not to say that resources are at times unproductive but they work on items that are not explicitly defined as their task during the times of float/slack.  For more senior resources, this can be assisting less experienced resources.  Cases can be made to begin a dependent task before the predecessor is complete.  Even in those circumstances where all tasks with float are started as their early start dates, these periods of float/slack continue to exist which moves us away from the 100% utilization implicit assumption.  This leads me to the conclusion that consultants should base pricing on duration and not effort.

 

So what do about this since the amount of float on any project is different?  We left off above with detailed estimates of either requirements or use cases that were defined by the individual doing the work that remains a good starting point.  From this starting point, defining the project schedule is the next step as it will have all the WBS dependencies, define the float for this project, and the timing of when resources are staffed and rolled off the project.  From here, I develop a project budget by laying down the staffing plan that defines on a week by week basis what resources are required on a project using the project schedule as basis for which resources are needed at any particular point.  Typically, I use a spreadsheet application to calculate on a weekly basis the cost of each resource, then sum the weekly amounts for a project budget and therefore price.

 

The above approach assumes consultants are 100% dedicated to a project that is almost but not always true.  In instances where multiple projects are utilizing the same staff, moving resources between projects will minimize the differences between pricing based on effort and duration.  In most consulting engagements, this proves difficult so the duration based approach has worked well for me.

 

Requirements: Are they a necessary part of a software project?

Historically, we have taken the approach of developing requirements through many different mechanisms.  We may ask the customer for an initial set.  We may conduct Joint Application Design (JAD) sessions where we conduct meetings for multiple days to extract requirements from our customers.  These techniques and many others remain a central part of many software development and implementation projects today.  Are these techniques still central to the process?

In the late 80's and early 90's, we began to see an interesting dynamic occuring.  When asking our customers for their requirements, a couple of results were commonly seen:

• The customers knew how their current system worked but had difficulty articulating what the requirements were and in particular identifying all the requirements.  Articulating all the system features was not something they thought about or did everyday so asking them was/is a very difficult task.
• The customers also tended to describe their current system and what it did as opposed to what the business needed the system to do.  Customers know their current system so a natural place to start was articulating how they used their current system, a logical conclusion but one that tended to design the solution including potentially unnecessary customizations in commercial software.

The common end result of these sessions was a set of features that did not meet what the customer needed and in many cases were just a subset of what the system needed to do.  Lay on top the duration of the activity and length of time to develop resulted in requirements changes and utlimately a dissatisfied customer as the solution did not meet the business needs at the time of production deployment.  The end result was projects going overtime and budget due to scope creep from the project team's perspective but necessary features from the business perspective.  Both positions were fair and justified.

As these dynamics became apparent, we began to develop several tenants that remain true today.

• Customers have a greater capability to describe what is needed when looking at a prototype of the solution or at least business processes.  Business Processing Re-engineering (BPR) has been around a long time and is not as prevalent as it used to be.
• Customers have a greater capability describing what they do on a daily basis and even infrequently.
• Working or partially working software is a better tool for understanding what a solution needs to do than any form of documentation.

This has lead us down a path where use cases and/or user stories have become a legitimate mechanism for defining what a system must do.  The prototyping techniques and now the agile methodologies all expouse this mechanism as a favored way to define the scope of a project.  Combine this with business processing modeling and the project manager has a different tool to define the "What" of the system.  Process modeling and use cases also provide four additional benefits:

• Is more systematic as the team's tend to look at all paths and not just the happy path.  In a process model, a decision point must have a Yes and No path to the question.  In many questions, one or the other is an edge case so can be overlooked when reviewing just use cases. Modeling has an inherent auditing capability that tends to drive more thoroughness.
• Provides a mechanism to look for process improvements.  In many cases and once the process is defined, customers can more easily identify steps or decision points that are no longer needed or can be streamlined.
• Is agnostic of the legacy application which enables the project team to define a design or configuration for commercial software unburdened by the legacy system.  For commercial software, this is particularly useful in working within a core product and avoiding costly customizations.
• Provides a better mechanism for the test teams to become involved earlier in the project.  When developing requirements, many test teams opt to review the session output and do not contribute to the requirements development.  By using modeling and use cases when the use cases drive the structure and scope of the testing, the testing teams are motivated to participate early.  The test team also provide a valuable service as they tend to be very systematic in thinking through edge cases and error scenarios resulting in a more complete set of use cases or process flows.

In summary, defining "what" the system needs to do remains a critical part of a project.  As we have evolved, how we define "what" has more options that now include business process modeling, use case or user story definitions, and prototypes as a substitute for requirements gathering.  When beginning a project, considering the appropriate mechanism for defining scope is an early and critical project management decision.

These mechanisms have different advantages depending on whether the project is a consulting project with a scope based statement of work whether it be a custom development or commercial software implementation or a product development organization developing and improving a commercial product for sale.    These pros and cons of these techniques with respect to the project type are a topic for a future post.

Personality Traits of Successful Program and Project Managers

We have all observed program and project managers who are successful.  They make it look so easy and to many it is easy, as they possess certain personality traits and skills that acclimate them well to the profession. But what are those traits and skills; and how do we identify them in our employees or candidates so we can build a strong program and project management team within our company.

Many others have written on the subject so below are excerpts that begin the list.  This list also includes what I would call skills of project managers and typical tasks that makes program and project managers successful.

CIO Magazine	Williams Company	the99percent.com	Recruiter.com	Project Times
They possess the gift of foresight	Be completely obsessed with the Client.	Command authority naturally.	Clear Vision	Be an extrovert
They're organized.	Provide crystal clear project goals and be accountable.	Possess quick sifting abilities, knowing what to note and what to ignore.	The Ability to Delegate	Display personal courage (lead from the front)
They know how to lead.	Communicate clearly and effectively in all directions.	Set, observe, and re-evaluate project priorities frequently.	Communication Skills	Possess charisma
They're good communicators	Define roles and responsibilities of all team members.	Ask good questions and listen to stakeholders.	Problem Solving Skills	Be an enabler with a can do attitude
They're pragmatic	Create a viable schedule with total team commitment.	Do not use information as a weapon or a means of control.	Leadership Competence	Have a strong sense of teamwork
They're empathetic.	Identify the big risk items and mitigate them early.	Adhere to predictable communication schedules,
	Prioritize ruthlessly.	Possess domain expertise in project management as applied to a particular field.
	Anticipate and accommodate change.	Exercise independent and fair consensus-building skills when conflict arises
	Challenge assumptions and self-imposed limitations.	Cultivate and rely on extensive informal networks inside and outside the firm to solve problems that arise.
	Manage the client’s expectations.	Look forward to going to work!
	Learn from experience and mistakes.
	Have an attitude of gratitude and thank those who helped you succeed.

Many themes jump off the above lists including:

Leadership

Leadership is identified separately from management, as leadership is more of a personality trait whereas management is a learned skill.  I recognize this is not a common view as many people and companies espouse courses in teaching leadership.  Here, I am identifying people who can motivate others as projects are long endeavors, which invariably have points where the success of the project falls to the project manager who can keep the team motivated and get them past the sticky problems observed on nearly every project.

PMs also have to instill confidence in both their teams and the manager(s) to whom they report.  As stated before, projects are long and difficult endeavors, which have plenty of challenges.  When these challenges arise, PMs who are able to maintain the confidence of all interested parties have more success.  When the confidence in the PM is shaken, executives tend to provide additional assistance to the teams that is a sure sign of lost confidence and adds additional effort to the project. The group of engineers will operate indepdently producing a fragmented solution.

People in general bring a set of implicit assumptions.  These assumptions are not typically in the forefront of their minds but exist due to their life experiences both personally and professionally.  These assumptions then drive the set of solutions they are able to envision.  When a PM is able to identify these implicit assumptions, validate their relevancy to the unique project, then challenge them if need be, better solutions to problems are identified.  These better solutions may be quicker and less risky to implement, require fewer resources or less highly skilled resources, or have a better impact on the business.

Management Skills

On all projects, there is a finite amount of administration that occurs and this to me is the management of the project.  The management component of project or program management requires multiple skills as well as traits.  The traits include the ability to organize.  Projects inherently have lots of moving parts from end users and sponsors with thoughts, to technicians who have commercial applications to configure or code to write, to test teams and configuration managers who have plans and backend support systems to bring on line.  All of these disparate groups must be brought together and coordinated so the project can move forward and eventually complete.  The ability to organize the multiple teams is a personality trait inherent is successful program and project managers.

We also have to organize at a deeper level when dealing with the technology.  The task of building a Work Breakdown Structure (WBS) is a feat in organization when done well.  Not only do business and technical executives have to understand both the strategy and tasking but also the technicians who will perform the work.  Laying out a structure that is understood by both disparate sets of people is difficult at best.  Now include the capability to track progress in a meaningful way for both groups and the need for deep organizing trait is paramount. 

Closely related is the ability to plan, to foresee how a project will come together.  Planning also includes what deliverables are needed, how and when to develop test plans, how many test plans are needed, what metrics are needed, and which resources execute which tasks in conjunction with each other.  All of these are unique to each situation as the Statement of Work (SOW) or Project Charter is unique as well as the scope undertaken and the resources assigned to the project.

The ability to manage both your own time and the time of those working for you is critical.  Projects have so many distractions making it very easy to head down a rabbit hole that derails the project.  These typically happen during the development phases but can also occur at any phase.  Contrary to popular belief, the highest risk time of a project is the beginning and not the end.  Many times I use an analogy of catching a wave for a surfer.  This is analogous to setting the scope and planning phases of a project.  Once you catch the wave, the time to the beach is out of your hands as the wave is going at its own speed.  You can make some moves that will have some impact on the timing but the base timing is already defined.  Successful project managers take their time in planning and resist the temptation to get starting developing because time is short.  Each project has numerous options on how to approach the work. It is this approach which is analgous to catching the right wave, that has the most dramatic impact on project timing and success.

Setting the priorities for individuals and managing to those priorities becomes a main activity during the majority of the project.  This requires the PM to handle multiple tasks at the same time.  The moment the first task is delegated, the PM is multi-tasking.  If an individual tries to handle all tasks themselves, a project of any size is at risk.  On a typical commercial software implementation, I will have the following threads open: 1) software configuration, 2) interface development, 3) conversion or data migration development, 4) custom software development, 5) communication with sponsors, 6) communications with consulting company management and sales, 7) project tracking and monitoring, and 8) potentially open core product issues or enhancement.  The ability to manage your time, multi-task, and manage the team's time is a critical skill.

All projects include the use of teams.  These teams include resources for which the PM has direct responsibility and other resources for which the PM does not have responsibility.  All of these teams must come together and work toward the common goal of completing the project.  The team will consist of not only these individuals but also the managers of the matrixed resources as they potentially have competing goals.  The ability to create and motivate teams becomes a determining factor in the success of PMs.

Communication Skills

The ability to communicate in both written and verbal form both up and down the management chain is a widely known required skill.  In the previous paragraphs and going forward the implication of communication skills jumps off the page.  Let me delve into a couple of areas that are not as widely held.  The first is with whom PMs communicate.  I have mentioned the need to discuss topics with business and technical leaders as well as the technicians but what is also needed is the ability to define or clarify technical or business problems to the opposite group.  Many times on a project I will come across a particularly difficult technical issue that either impacts the dates or is a risk to those dates.  Naturally, both the technical and business leaders want to understand the problem.  Given it is a technical issue in this case, discussing technical issues with technical people is easier than helping a business leader understand why the web application crashes because of Java Virtual Machine (JVM) Heap is exhausted and why this is a problem given the CFO just spend dollars increasing the memory on the application server.  These are important topics for them to understand as well as the opposite.  Helping the technicians understand why a good technical solution has dire consequences for the business side of the house.

PMs are also knowledge conduits.  They should ensure that information from one team gets to all the other teams that need it.  As project schedules get tight and the tension begins to increase, many people naturally focus on their tasks at hand to become more efficient and get their work done.  A great thing for that individual task but what happens when the other teams need information from this one group and cannot get it.  The other tasks naturally fall behind so the project falls behind.  The PM that stays in touch with what all groups are going and moves the information between groups can more effectively keep all tasks moving and avoids disconnects when the “right” hand is not talking to the “left” hand.

Foresight and Vision

Some people have the innate ability to see the future.  I am not talking about crystal balls or palm readers but a sense for the direction the project is headed and the ability to see risks and envision how all the elements of a project will come together in the end.  I alluded to this concept in the planning section and it applies here as well.  In conjunction with planning is the skill of defining goals for individuals that are in sync with the plan.  In my post, “Staying on Schedule”, I spoke about intermediate milestones and mini-crisis as a mechanism for maintaining a schedule.  The ability to foresee, define, and articulate these goals goes a long way toward staying on schedule and being successful.

Risk management is a key aspect of successful projects and is in many instances not well received as an integral part of a project.  In many organizations and as an attempt to manage time, organizations only deal with issues and not risks.  Many times, I have highlighted risks to be told we will deal with it when it becomes a problem.  The personality trait to envision a risk and the capability to address the risk are key elements to success.

Pragmatic

As PMs we are constantly in the situation of making choices.  Usually all day is spent making trade off choices between competing forces.  There are times when we have to make a choice a deliverable is good enough, not perfect but good enough as it meets the business objectives.  The prime example comes when dealing with the speed at which application pages are rendered.  I routinely hear from end users and sponsors that I want the page to be as fast as possible.  From a conceptual standpoint, this makes sense as speed of page rendering translates into efficiency of workers and eventually money.  Fast as possible does not mean get 6 Cray super computers for my solution or that I want sub second response time on a page that is making two web service calls and returning a three table join query.  Clearly, neither is going to happen.  What was meant was to increase the speed until it reaches a good balance between cost, time and speed.  This is not a straightforward decision.  The technician would ask for the performance requirements so they know the solution to build; the businessperson wants a reasonable cost so the PM is in the position to determine what is good enough.  The balance point falls to the PM and pragmatism is key.

Conflict is also a common occurrence on projects.  It can be between two technicians, the test team, developers, the business people, etc.  The ability to work through issues and even decide on what issues to engage is something critical to success.  People can be passionate about what they believe in so getting past these points of contention whether it be negotiating a resolution, facilitating the discussion or deciding which battles to fight becomes important to success.

Can do attitude 

In our world, there are people whose glass is half full and those whose glass is half empty.  The perspective on adversity, challenges, and dealing with people go a long way toward success in a work environment that typically includes strict deadlines, changing requirements, heavy budget pressure and big business impacts when the project does not go well.  A can do and positive attitude is a personality trait that serves PMs well dealing with adversity, the high-pressure situations, team building, and leadership.  Finding this personality trait in a person serves them well in the profession of Program and Project Management.

In addition to the above list of skills and traits, I would add a personality trait of cool and thoughtful under pressure.  Projects are intense, long, and difficult activities that have periods of time when the PM is under significant pressure due to impending deadlines, difficult issues, etc.  People are also very passionate and so the PM is typically under a lot of pressure and must be able to think on their feet and remain thoughtful during the intense times.  It is these times when PM can easily lose the confidence of management or their teams, lose control of scope, or any number of other occurrences that negatively impact the project. 

There are three inputs in the table above I would not agree with:

1. Be completely obsessed with the Client.

Client focus to a degree is a very good thing.  In situations where the project manager is also managing a team and a contract then a proper balance between these many times competing agendas enables the project manager to not only meet the client goals but also individual and company goals.  In these situations, the project manager has multiple people and organizations to which they report and must meet the goals of each individual and organization simultaneously to be successful.

    2. Be an extrovert

Due to the need for extensive interaction with people, extroverts typically have these skills inherently.  Individuals who straddle the introvert/extrovert category can also be successful as they can communicate and operate in the people centric situations.  Strict introverts who prefer to work alone and on individual tasks will struggle in the PM role.

    3. Display personal courage (lead from the front)

In my previous post, I discuss the relative timing of leading from the front and back.  Different situations dictate assuming each style so both are needed and not just leading from the front.

The personality traits and skills needed for project managers to be successful are varied.  When interviewing PM candidates and identifying internal candidates for a PM role, these people centric traits and skills are far more influential in the success of PMs.  What may be interesting to many people is the lack of technical expertise as a main contributor to success.  Certainly, technical and business expertises are needed for a project to be successful but are typically skills for others on the project.  With the exception of enough domain knowledge to understand the business goals and to speak intelligently to business leaders, the other traits and skills are much greater contributors to the success of a Program or Project Manager.

 

 

9 Beliefs of Remarkably Successful People

This article by Jeff Hayden and published in Inc Magazine was so engaging and spot on I had to publish.