Saturday, April 25, 2009

Do we really need a Project Charter in Software Applications Development?

In a small shop, creating an app for in-house use, requested by the owner, possibly not. But, whenever an expenditure of assets or resources is required, there should be some document authorizing those expenditures & the reason for making the expenditures. The charter is external to the project & defines the project in terms of the customer's business needs or market demand. It's usually created by the project's sponsor or initiator. This could be entirely internal, or it could be partially external, as in the decision to respond to an RFP, or it could be completely external, as in the case of fulfilling a contract. Being a PMP, I use the term Project Charter, but the name of the document is not as important as the elements it contains & the purpose it serves.


The Project Charter documents the requirements & the new product, service or result that will satisfy those requirements. It is the definition of the project, agreed to by all the initiators of the project. The basis for the charter may be a contract or statement of work. That document should contain at least:

  1. The client's requirements & business needs
  2. The project's purpose &/or justification
  3. The PM & authority level to spend or acquire resources
  4. Summary Milestone schedule if necessary
  5. Identification of stakeholders & their influences
  6. Functional organizations & their involvement
  7. Assumptions
  8. Constraints
  9. The Business Case & summary budget


In my experience, except in the case of external contracts, I've rarely had a document that contained all of the above, but in the absence of any of this information, the first thing to do is try & obtain whatever is missing, & obtain it in writing. Much of the necessary information, even if contained in the authorizing document, must be elaborated anyway, especially in the case of 'legally required provisions' not explicitly defined in the document. If the equivalent of the project charter is a set of other documents providing essentially the same functionality as a Project Charter, it's not a bad idea to collect all of these documents & create a Project Charter, with the original documents as attachments, for the project sponsor to sign. There are numerous Project Charter templates & examples available on the net . Alternatively, if there is an electronic workspace for the project available, copies of the documents can be stored there, under a Project Charter Folder.

(As an aside, a common, accessible, project workspace is an invaluable asset, because it can contain up to date documents on all facets of the project. In Lotus Notes or other similar work group applications, a Project Conference, or document within a Projects Conference, can be a common accessible place to either put project documents or links to project documents.)



The client's requirements & business needs


I'm reminded of the Dilbert cartoon where the Project Manager asks " What do you want the software to do?", & the response is "Tell me what you can make it do". In the absence of requirements, how do you know what product or service to provide? So let's assume you will have at least a high level definition of the requirements. Without a definition of the business needs, both you & the customer may be solving the wrong problem. An analysis of the business needs can also help in prioritizing & phasing the project, & especially in defining the deliverables.



The project's purpose &/or justification


This might seem to be the same thing as the business needs, but it's more related to the reason, rather than the need. There might be plenty of projects that fulfill some requirements & business needs, but are not in line with the organization's business strategy or whose justification is not in line with company policy or vision. For instance, the software requirement might be to
change a numbering scheme for identification of particular objects in a drawing application. There is a business need because newly obtained customers switched over from a competitor are used to this different numbering scheme & are demanding it. The requirements are defined & so are the business needs, but the purpose is not to provide the new capability, it is to increase new customers comfort level with the software.


The Project Manager & authority level to spend or acquire resources

Hello! This is your project. You can spend up to ? ($, hours, ...). You can have ? resources. Hahaha! More likely, you will be given authority to spend just enough in time, money & resources to initiate the project & set up the project plan including the prospective budget & resource requirements. But, at the very least, you can begin the process. The most important thing is that this is where the Project Manager is named & is given responsibility for the Project. From this point on, the conduct & outcome of the project belongs to a single individual & point of contact.

Summary Milestone schedule

If there are contractual milestones, or immovable dates ( e.g. a trade show or Federal reporting deadline), these should be spelled out. These milestones are customer, legal or organizational in nature & are not subject to slip or negotiation. Other milestones may be developed as part of the project plan but those are plan driven, not requirements driven.


Identification of stakeholders & their influences

The Project Manager's main obligation is to get the job done, but most of the work done by the PM is communication. Stakeholders are anyone who can influence or be influenced by the project. Whether sponsor, customer, team members, other functional managers, supervisors, vendors, or the public. The Charter spells out, at the very least, the stakeholders from the customer & sponsor's point of view. Additional stakeholders will be identified by the PM
during an analysis of the Project, but the stakeholders spelled out in the Charter are likely to be the ones most interested in the project's success.


Identification of the functional organizations & their involvement

Most of us work in a balanced matrix environment. If our software project will require resources or input from other departments or organizations, we’ll need to know who they are, & what contribution to the project they will make. We might need contract specialists, engineers, facilities people, etc… If these other departments’ involvement is required, they need to be specified. If their involvement is not required by the contract or explicit in the charter that does not mean that these dependencies don’t exist, only that they will need to be identified later
on in the planning process. The charter should at least provide authority to acquire resources from other functional organizations as required.


Assumptions

Assumptions may involve the availability of resources, technology, access to the customer/end user, facilities, knowledge, funding, etc…. All assumptions carry a degree of risk based on their likelihood of being true. Assumptions explicitly documented in a project charter must be treated as true, real or certain. If these assumptions are agreed to and signed off on, they form a contract which can then be used as the basis for planning. Even so, they must be listed on the risk register, even with a low percentage of likelihood, since their impact can be considerable.


Constraints

Both constraints & assumptions limit the team’s options for resources, staff, scope & schedule. If there are contractual constraints like defined delivery dates, budget considerations, buy vs. build specifications, lists of acceptable vendors or products, minimum requirements, performance penalties, reporting requirements & dates, etc… these should be documented & agreed upon up
front. There are always constraints & if your initiating document does not contain them, you should determine them as soon as possible & get them documented. No one has access to unlimited funds, staff, facilities & time.


The Business Case & summary budget

The Business Case deals with ROI or the perceived benefit to the company measured against the costs or risks associated with the project. It is usually done before the project is given the go ahead & is based on the project getting done for a cost not to exceed that calculated during the analysis of the project by its sponsors or initiators. Usually, alternatives have been analyzed as well and may be listed along with the reasons this project approach was chosen rather than the alternative. In any case, the business case & summary budget provide both the framework &
the context for the project. In my own experience, I seldom see the business case, but I often see the summary budget, which becomes one of the primary constraints. Indeed, after I do my own budget for the project, comparing it to the summary budget brings the risks associated with the project into greater focus & leads to later go – no go decisions. The business case should be revisited by the sponsor, organization & customer at regular intervals to ensure that it is still valid, & even though this is not a PM function, it certainly impact the project.



Summary

The charter is the first document the PM sees. It defines the project’s goals & rationale. It sets the limits & identifies the players. I’d hate to start a project without that information.





Monday, April 20, 2009

Project Managment Increases Applications Development Success

Project Management for Software Applications Development is not much different than for any other Project Management field. What's different is the success rate. According to the Standish Group's Chaos Report, half of all software projects end up either late, over budget, incomplete, or failed. Of course, many software development projects are led by developers with little formal training in Project Management. Absent such training, such results should not be a surprise.

Software projects are plagued by a lack of well defined requirements, poor estimation techniques, faulty or non existent change control & other process failures. Even CMMI, which measures an organization's maturity, & ISO, which measures an organization's adherence to repeatable processes, are no guarantee of success. Of course, the success rates for organizations with mature, repeatable & verifiable processes is greater than for those without them, but even so, Project Management processes can improve the success rates even more.

Looking at software application development projects, the triple constraint defines the failure modes, just as it does in any project management environment. Software projects fail by being late (Schedule), over budget (Cost), or not delivering the required features (Scope). A normal software development team ( System Architect or designer, programmers, UI experts, testers, documentation specialists & deployment specialists, etc...) may be excellent at what they do, but most are not trained to do the business or communications functions, or change control functions so necessary to ending up with a successful product. It's true that some developers relish the interaction with stakeholders & the negotiations over scope change. These individuals are probably good Project Management candidates & would benefit from some formal training. I'm speaking from personal experience in this regard, having been a software developer for 30+ years & a software project manager for almost as long, & while I'm not an expert in all facets related to software project management or software development, I at least know what should be looked at, & where to get whatever specific expertise or skills that are lacking in the development team.
During the requirements phase, a Project Manager is looking to define & solve the problem, not to ease the symptoms. A Project Manager knows the relationship between risk & cost, effort & schedule estimates. A Project Manager knows that expert judgement without metrics is negatively correlated with good estimates & that without a change in process, that past experience is the best indicator of future performance.
Project Managers know that without a good change control system, Scope creep is inevitable. Personally I'm a believer in iterative development & understand that in creative endeavors like software development, even the best can not be expected to predict every necessary system requirement, but I do believe that change can be managed. Project Managers know that sometimes it is better to buy than to build, & that sometimes it is better to outsource or to contract than do it in house, especially when specialized knowledge is not available on the team. Project Managers also know that without lessons learned, the same faulty processes & decisions will continue to be repeated.
In future blogs, I'll take an individual Project Management Process & relate it to Software Applications Development, or I'll take some aspect of Software Applications Development & show how Project Management processes can make the outcome more predictable & successful. As always, your comments & suggestions will be very welcome.

Why doe Software Development Projects need Project Managers?

Project Management is not much different for Software Applications Development than it is for any Project Management field. What's different are the results. According to the Standish Group, half of all Software Projects are either late, over budget, or don't deliver the original scope. Even though this is a vast improvement in the years since it's inception, it's still an abysmal record. Many software projects are led by software developers with little knowledge of project management. Absent such knowledge, such results shouldn't be a surprise.

Software projects are plagued by a lack of well defined requirements, poor estimation techniques & faulty or non-existent change control, etc... All in all a breakdown of process. Even CMMI, which measures organizational maturity, & ISO, which defines repeatable processes, are no guarantee of success, although, repeatable verifiable processes will certainly better the odds of successful delivery of a software project.

Looking at software projects, the triple constraint defines the failure modes, just as it does for all project environments.


Thursday, April 16, 2009

Applications Development & Project Managment

Applications Development is a natural environment for Project Management. It usually involves specific features for a specific market or user group. It can usually be broken down into a list of features ( requirements), which can be analyzed for dependencies & prioritized based on value. For mass distribution applications, however, this prioritization may be more connected to market research than to interviews with a small number of stakeholders. Time to market is always a prime driver. Who gets there fastest wins. In an environment like this, project managers have a responsibility to ensure that their customers get the most value as quickly as possible. Agile development methodologies are more suited to this kind of development. Continuous feed back driving iterations will require more planning & management rather than less.

Protoypes, mockups & visualization tools can help obtain feedback. OODA loops applied to prioritization & development decisions will aid in evolution of the product. Ensuring that this iterative development stays focused on the final goal becomes more of a challenge, because feedback can alter the vision & the goal. However, iterative development also aids in quick delivery of value, which helps in the 'first to market' arena.

Normal Project management processes undergo slight changes in timing & emphasis. Change Control becomes intimately linked with planning, Uncertainty on any one iteration is reduced, because each iteration becomes a mini project, but it's reduced scope reduces risk. The entire application's uncertainty is increased because it's more difficult to see the end of the iteration process, especially when each iteration can lead to vision & scope change.

For Project Managers this is anathema, but the rigorous use of applicable Project Management processes is even more important in a rapidly changing environment to prevent chaos.