You are on page 1of 9

Four Key Elements to Successful Project Structure

Aaron Griggs
George Mason University | Systems Engineering | SYST 530 Spring 2005 Edited February 2012 for submission to Stevens Institute of Technology Ph.D. application

INTRODUCTION
Project management is marked with the triple constraint of cost, time and performance.1 Much has been documented on controlling these items. No matter how many techniques or processes are detailed, success is still determined by the people that staff the project. As the leader, the project manager (PM) must build a structure that delivers under numerous constraints and variables. Four key elements: foster, define, delegate and guide provide a framework for a successful project structure. This paper examines software development projects and processes to illustrate how important the project structure is to success.

FOUR KEY ELEMENTS


While no four or four hundred things guarantee success, an examination of four key elements does provide insight into building and maintaining a successful project structure. First, the project must foster a good working environment. Many organizations are unaware how simple changes in the office surroundings and workplace culture drastically improve productivity. Next, the project is supposed to build something and that something must be defined clearly. While it sounds simple, figuring out what to build and why is overlooked by many. Also, defined roles and responsibilities are required. Delegated authority within the roles leads to ownership and accountability. Lastly, a guiding influence is required to keep everything working together. Many times successful projects are not marked by specific points of leadership but rather a collection of guiding influences. An understanding of the key elements: foster, define, delegate and guide provide the PM with the framework to succeed.

Project Structure Benefits


Before detailing the specifics of each element, a look at why a project structure is relevant is in order. The project defined by the triangle (triple constraint) of cost, time and performance illustrates the relationship between competing factors. For example, requirements (performance) creep will lead to increased costs to implement the changes and possible schedule slippage. Factors affecting the triple constraints are inevitable. The project risks must be mitigated by the project structure. The project structure is basically the project team including people, tools, processes and products. The team should be equipped to absorb impacts and still deliver successfully. The four elements provide the framework to handle the numerous issues that arise.

2012 Aaron Griggs

Four Key Elements to Successful Project Structure

As shown in Figure 1, the project is contained within the project structure. The figure illustrates that the project structure is more than adequate to confine the project noted by the extra area around the project triangle. In other words, the project team is equipped to handle it.

Figure 1: Adequate Project Structure

Figure 2, demonstrates inadequate project structures that show the project triangle is outside the confines of the project structure. The team is not equipped to handle it.

Figure 2: Inadequate Project Structure

While this example is trivial, the evidence that a structure must be in place is clear. Next, an examination of the project structure as defined by the four elements is provided.

2012 Aaron Griggs

Four Key Elements to Successful Project Structure

Foster
When an organization looks to positively impact project structure, a common overlooked area is the environment in which the team works. Much tasking in software development projects requires an individual or small team to concentrate for hours at a time uninterrupted. Everyone has been there where they get into the zone and the hours melt away as knowledge flows from thought to execution. Whether it is the systems engineer writing up specifications, the software developer knocking out code or the tester validating numerous use cases, the same principle applies. The individual was able to get into a state of consciousness where knowledge just flowed.2 The idea of flow is nothing new. In fact, most everyone has experienced it many times as well as being zapped out of the zone by interruptions. People are unable to get into the zone instantly. There is some immersion time usually fifteen minutes or so. If an individual or team needs to get knowledge work done, the environment should facilitate it. Now looking at most modern companies, where do the vast majority of workers sit and work? Well, in cubicle land of course. Cubes are a land of equality where everyone gets the same uniform environment which is to say everyone is at the least common denominator. The cube environment is full of many distractions that keep people from concentrating. Fences make good neighbors and office doors make good co-workers. In cube land, most people do not hesitate to interrupt each other, talk loudly on the phone or carry on group conversations. Now some companies understand this and basically give every employee an office. If companies truly understood the productivity lost due to cube land environments, many would follow suit with spaces designed to facilitate flow. Next, the daily interruptions of non-task related activities are a huge drain on productivity.3 Understanding that knowledge workers require uninterrupted long stretches of time, why would a PM schedule meeting after meeting bringing in everyone involved on the project? The answer may be to show how many people the PM oversees. Probably, the biggest productivity and moral sink is the daily, weekly or other recurring status meeting. This is the meeting where team members relay their status to the group which means to the PM. If involved in such a meeting in the future, look around at the team and see if anyone is paying attention. The blank stares and doodling is epidemic. The PM should have gotten every team member to email a quick update to compose a status report. What ends up happening is the meeting prevents most from starting a task due to the impending meeting. Then people are drained from the meeting that they delay even further getting started on the task. Meetings are a part of project life. However, focusing the meeting to satisfy concrete objectives with as little people as possible is a step in the right direction. Some have gone to extremes such as requiring team members to stand during the entire meeting to prevent wasting time.4 Interruptions aside, another major obstacle is finding the right people. In knowledge work and software development in particular, the right people can have a huge impact on productivity and completing projects on time. Studies have shown as much as a 10 times increase in productivity from one software developer to another.5 And probably more interesting is how the productive individuals are found grouped together. Productive organizations employ productive people and

2012 Aaron Griggs

Four Key Elements to Successful Project Structure

teams. Now whether the productive people caused the organization to be productive or the other way around, it is clear that the environment is a large influence. Lastly, the environment should demonstrate to the team members they are respected and valued. New York City underwent a dramatic urban renewal in the 1990s. Mayor Rudolph Giuliani basically declared war on crime and neglect of all varieties. Giuliani was heading the advice of Wilsons and Kellings broken windows theory.6 Basic tenet is if a broken window in a building is not repaired other windows will follow due to demonstrating that no one cares. While still under some debate whether the Giuliani policy was responsible for the dramatic decrease in crime, it is without question that showing someone cares does foster care by others. Projects and companies should demonstrate care for team members by paying attention to the little things that affect daily life.7 A toilet that is always out of order, the constantly empty water cooler represent the organization does not care about the employees. Great companies demonstrate in many ways the employee is the most valued resource. The respect demonstrated by the organization is almost always returned by the employee. The respect for team members should factor in their lives outside work as well. Driving up productivity using unpaid overtime is a common trend at software development companies.8 In fact, overtime is worn like a badge of honor at many firms. Bragging about how little time is spent away from work is supposed to signal commitment. In many instances, the commitment is at the expense of other responsibilities. The problem with this approach is other team members that fulfill the other commitments like spending time with their family are treated as contributing less or must make a decision between work and family. A company culture that embraces overtime is asking for trouble through burnout, turnover and resentment between team members.9 Many organizations now institute a flexible schedule with a 40 hour work week over a 7 day period. The PM must factor in the organizational structure with respect to the project teams time and other commitments. Also included is the ability for the team members to expand professionally outside the project constraints. Allowing the team to expand both personally and professionally through other means than just project time, the individual becomes a better organizational citizen and a more valued project member. Understanding that the environment plays a large part in projects, the organization and PM should pay attention to the workplace environment. The physical layout should promote flow; the PM should avoid extraneous meetings and understand there is a need for work/life balance. By fostering a positive work environment, there is a higher chance for project success.

Define
In many instances, a technological wonder of a software product is built but the customers or stakeholders are far from pleased. Usually, the mistakes were made in the upfront definition of what was to be built. Hazy requirements are the norm and the malleable nature of software yields to ever changing requirements.10 The cost of changing software is often obscured since there are no walls to tear down or visible physical instances. Therefore, the necessary definitions of what is to be built are overlooked.

2012 Aaron Griggs

Four Key Elements to Successful Project Structure

How can a software project define what is to be built when it may be near impossible to come up with concrete definitions? The answer is found in several areas. First, key objectives or a vision statement should capture what the project or sub projects are to accomplish.11 An important aspect to the vision statement is what the project is not trying to achieve. By explicitly stating what is not required, the haziness is reduced. A clear vision is the basis for all other requirements. After the vision is clear, a specifications document should explain what is being built that satisfies the vision. The software features are derived from the vision statement into a focused specification document. Note features are used interchangeably with requirements but are differentiated by the notion that a feature is a grouping of requirements to solve a specific business problem. A collection of specifications make up the project features. The reason features are described in separate specification instead of grouped in one large document is for iterative software development and release management. Iterative development consists of milestones which contain one to many features and thus specifications. A release of a product version consists of several milestones.12 The idea is certain features are well understood and considered crucial. These are grouped into a Milestone 1 which consists of coding, testing and debugging then stabilization. Other features are elaborated to satisfy the vision and are incorporated in later milestone which may also contain unanticipated features due to emerging market demands. If schedule slippage occurs (which it always does), certain features may be deferred or cancelled. Figure 3 illustrates the relationship of specifications to releases. Specifications may be written at any time to encapsulate a feature and create a project pipeline.

Figure 3 - Release Management

2012 Aaron Griggs

Four Key Elements to Successful Project Structure

The specification should avoid describing how the feature is designed. Prototyping may be done to provide proof of concept; but, the actual design is left to the implementers (software engineers/developers). The major focus of the specification is what is to be built. Delving into design will likely corrupt the specification and also disrupt the division of labor. Of course, the same team member may build specifications and write code. However, the member should clearly delineate what from how. After specifications are in some semblance of order, a time estimate provided with major input from the implementers is compiled to build a schedule for implementation. In many software projects, either the specifications are not used to estimate schedules or the estimations are done by individuals that will not be building the product. To develop an accurate schedule, the developer must provide the estimates.13 There are several benefits to this type of estimating. First, the specification should be detailed enough to allow the developer to understand the tasking. An experienced developer will indicate if a feature is too hazy to provide an accurate estimate. Next, the developer is responsible for building the software and will strive harder to meet her own estimates. Not to mention, it is a great learning tool for developers to estimate tasking based on specifications since it will ultimately increase their accuracy and efficiency to understand the steps of building the software product. Also with more accurate estimates, the feature list (specifications) may be scoped to meet specific schedule deadlines. In many cases, the deadline is already set due to marketing commitments and sales cycles. Therefore, a more accurate feature set can be scoped and implemented to meet the deadline. The specifications as inputs to the estimates provided by the implementers provide a sanity check and greatly increases schedule accuracy. By incorporating a phased approach of vision statements, specifications and accurate time estimation, the definition of the project is better understood. The chance of success is much higher with clearly defined project information.

Delegate
Similar to project lifecycles with phases for various work products, the project team employs division of labor to accomplish tasks. Specific roles and responsibilities are required by various team members to successfully complete the project in the allotted time. In software projects, the chain of command usually consists of individuals with substantial technical experience in previous projects. That is, a PM may have been a system architect or lead software engineer on previous projects. This strong technical background can cause conflicts and problems with delegating. However, giving up power and direct control over results is necessary. Roles and responsibilities are crucial on most software projects with clearly defined roles, to include systems engineer, system architect and tester. There are other roles such as technical writer; but, the three listed above suffice to demonstrate why proper delegation is necessary. The trend in many modern software organizations is to cut costs by staffing just developers who can also act as the systems engineer, architect and tester. The problem is one of roles. Without a focus on systems engineering, the specifications are nonexistent or underdeveloped or prototypes become the product. Without an architecture focus, conceptual integrity is lost and spaghetti code ensues. Without dedicated testers, regression testing is ignored and more bugs develop as

2012 Aaron Griggs

Four Key Elements to Successful Project Structure

more enhancements are added to the project. All these are traits in modern software because management thinks money is saved by a one-stop handyman approach. First, a systems engineering approach is required. As discussed in the define section, the what of the system is the foundation of the project. The systems engineer takes stakeholder input and develops features into specifications. The relative cost to fix a bug (or add a new feature) grows extensively the further in the lifecycle the bug is found.14 Therefore, it is important to concentrate a role on figuring out what to build since downstream change is quite expensive. Next, the system architect maintains conceptual integrity. In software projects, integrity includes system interfaces, coding standards and software frameworks. A technical guiding hand saves time and effort in both the implementation and maintenance phases. The maintenance phase of software should be a major driver for a system architect. Cost estimations vary but research has shown that as much as 90% of the total cost of a software product is devoted to maintenance.15 For contracts where operation and maintenance are lucrative, it may make sense to have a lot of fixing to do. But for most software projects, maintenance costs detract from new features and profits. Lastly, the tester role is neglected as a core discipline. There are numerous reasons dedicated testers or quality assurance is not implemented. A popular one is the tester would cost too much money. However, high priced programmers are repeatedly used as testers; and, if required to test too much, tend to quit. Then, it takes a lot of time and money to find and train a new developer. The cost of replacing project team members is beyond the scope of this paper but a sorely misunderstood and underestimated cost.16 Without solid testing, including regression testing, bugs will leak through and incur the expensive downstream costs to fix. Also, testing is not all that exciting and the organization should understand this. Testers will come and go. A solid test director and relevant tools should allow the testers to cycle through yet still provide quality testing. Now that the importance of roles is understood, responsibility is addressed. In most instances, responsibility comes with ownership. If an individual has no ownership, why would they feel responsible for the results? One of the major reasons behind making home ownership a big tax break in the United States (home improvement and interest expenses are often tax deductible) is the idea of responsibility. When people own their homes, they take care of the house and the neighborhood thus improving the environmentno broken windows. The same is true of business tasks. Assigning a developer a task and telling them they have two weeks to complete did not involve the developer in the decision process. As mentioned previously, the developer should have a direct influence in tasking schedules. Such ownership makes the developer more responsible. The same principle applies for most tasking on the projects. The system architect should not dictate algorithm usage in a specific software module. Rather, the developer should decide with input from the architect.17 Delegation is accomplished by defining roles and responsibilities and giving up direct control over task execution. While a rigid and fully documented task list is not required, providing general guidance on what is expected of team members helps to focus effort and facilitate innovation. The project succeeds due to team work where various talents contribute.

2012 Aaron Griggs

Four Key Elements to Successful Project Structure

Guide
Leading a group of engineers and scientist who are domain experts with specific focus areas is a balancing act. Some engineers may be deliverable oriented with a desire to complete tasks. Others love to approach issues from many angles and not deliver much of anything. The PM must guide the project through understanding, decision making and communication.18 First, understanding the problems require the PM to be versed in the issues. As discussed earlier, clear definition of the requirements goes a long way to understanding. Asking why this problem is important and understanding of the issues both from technical and business perspectives provides insight. In information technology, the technical issues obscure the business view many times. For example, the hype of new technologies may entice the development team or management to push for adoption of technology before fully understanding the impact the technology has on the business. The 80/20 rule which was fashioned by Italian economist Vilfredo Pareto in 1906 after he observed 20% of the people owned 80% of the countrys wealth has a lot of bearing on technology projects. In technology endeavors, 80% is understood and the project is up and running until that 20% gotcha strikes. The 20% haziness may lead to 80% of the cost or likely 100% failure to meet some of the core objectives.19 After understanding is accomplished, decisions must be made and executed. In the decision phase, tasks are assigned to team members. Leaders owe it to the team and organization to track task progress. A long thorough process to figure out the direction of a project usually involves the best and brightest of the project team. However, execution of the plan falls to all project members. Allowing implementation of project plan decisions to flounder is a common mistake. The PM through project reviews and status reports can track progress and take actions. Actions may involve correcting poor performance specifically addressing poor performing team members. Leaders are often worried how firing an individual will affect the team. However, little thought is given to the message sent when allowing a poor performer to remain. Decisions must be made at every level of the project on every conceivable task. The leaders decision making habits set the tone and empower team members to assert control. Decisions must be communicated throughout the organization. If a team member is not fully aware his responsibilities, confusion will lead to poor execution. The same is true for organizational understanding of decisions. Many a team or companywide meeting has begun and ended with here are the decisionsany questions? This is not a communication of why the decisions were made. The understanding and decision phase should be leveraged to clearly communicate the basis for the decisions. By including the team during earlier phases (before the actual decision is made), they become more comfortable with decisions. Every day communication opportunities come and go with the barrage of meetings. Effective leaders communicate to the meeting participants: what was decided, why and who is responsible. A quick email after each meeting can suffice. Instead of the meeting being a waste of time, tasks are enumerated and responsibility assigned. A summary action report at the end of each meeting will focus the team and produce results. As a side effect, a meeting that was a waste of time will be captured in a persistent form and hopefully avoided in the future.

2012 Aaron Griggs

Four Key Elements to Successful Project Structure

Leadership takes many forms. Yet a common theme of understanding, decision making and communication exists. When team members understand what is expected and why, the team works towards common goals and accomplishes objectives.

CONCLUSION
Four key elements: foster, define, delegate and guide; are not a panacea for successful project management. As this paper demonstrated, elements such as these four provide a foundational framework. Recognizing the impact the environment has on productivity enables the organization to foster a positive workplace. Defining clear objectives provides a common point of view. Delegating authority empowers team members to assume ownership. Guiding through sound leadership keeps the project focused. These four elements provide a framework for a successful project structure that many an organization can adopt.

REFERENCES
1 2

Project Management Institute, Project Management Body of Knowledge, 2003. DeMarco, T. and Lister, T. Peopleware: productive projects and teams. Dorset House Publishing, New York, 1999, 62-68. 3 DeMarco and Lister, 215-221. 4 http://www.extremeprogramming.org/rules/standupmeeting.html 5 DeMarco and Lister, 42-50 6 Wilson, J. and Kelling, G. Broken Windows: the police and neighborhood safety. Atlantic Monthly, March 1982. 7 Buchanan, L. Harvard Business Review April 2005, 20-22. 8 Cusumano, M.A. and Shelby, R.W. Microsoft secrets: how the worlds most powerful software company creates technology, shapes markets, and manages people, 1995, 93-95. 9 DeMarco and Lister, 179-180. 10 Brooks, F.P., Jr. The mythical man-month: essays on software engineering, Addison-Wesley, Boston, 1995, 184-185. 11 Cusumano and Shelby, 207-210. 12 Cusumano and Shelby, 192-198. 13 Spolsky, J. Joel on software: and on diverse and occasionally related matters that will prove of interest to software developers, designers, and managers, and to those who, whether by good fortune or ill luck, work with them in some capacity, Apress, 2004, 77-88. 14 Buede, D. The engineering design of systems: models and methods, John Wiley & Sons, 2000, 24-25. 15 Bennett, K., Gold, N. and Mohan, A. Computer Bulletin, British Computer Society, January 2005. 16 Splosky, 170-177. 17 Brooks, 45-47. 18 Drucker, P. F. What makes an effective executive. Harvard Business Review, June 2004. 19 Kane, D. Loosely coupled: the missing pieces of web services, RDS Press, California, 2003, 53-54.

2012 Aaron Griggs

You might also like