Introduction

Planning, estimating, and tracking the progress of your portal project is not a new concept. Probably the most common question asked of any development team by outsiders and management is, "How is it going?" While, at a gut level, most team leaders know if things are going well, some type of tracking is the only way to really measure where you are, and to explain the status to your project sponsors. Even the simplest of projects need some type of plan or list of tasks. Checking things off your task list can be one of the most satisfying aspects of a project--aside from actually finishing and going live, of course.

There are many approaches to project tracking, with many of them embedded in tried and true methodologies. However, where do you start? Walking into a project cold or being asked to assist or run a project from the very beginning can sometimes be more stressful than the project itself. Team members should understand what approach they are going to take when giving estimates or breaking down tasks within a project. However, just as important as good estimation is tracking the progress of a project as it proceeds.

While this article in our series covers the concept of project planning and tracking, the authors are not project managers. Rather, we are portal practitioners who have been through "trial by fire" projects more than a few times. Therefore, this article is targeted at all the leadership within a project team. Project managers can read this article to learn more about the specific nuances of portal projects and, hopefully, get some new ideas to share with members of their own projects. Other practitioners, such as architects and development leads, can try out some of the ideas discussed to improve the success of their project.

Wait! I’m not a project manager

Sometimes we hear technical people say, "I'm not a project manager, I shouldn’t have to do this stuff" or "I should only be doing the technical stuff." Our response has overwhelmingly been, "Get over it". If you want to be a leader, you are responsible for much more then just "the technical stuff". Your responsibility is to the success of the project as a whole, and that includes being able to define, estimate, and track the completion of the components and your team members’ progress during the course of the project. You might even start to enjoy it.

Anyone with good technical skills can create architecture diagrams, write and review a technical design, or even write some code. Being a project leader means knowing when a project is headed off track, or when a team member is in over their head. It is also about knowing when estimates are way too low and that something will not be finished in the ridiculously short time your project has scheduled. Adding to the success of the project means understanding the day-to-day activities of your team, the hours they spend, and, in larger projects, obtaining the weekly status of each member to assist the project manager in overall tracking.

As architect or technical leaders, we live with the day-to-day activities of the project team. One style is to talk to each team member, every day. Some people feel that this approach helps the leader to keep a constant pulse on the team and its progress (most of the time). A daily 5 to 10 minute conversation with every team member helps you insure that:

• Tasks are defined correctly and understood by the team.
• Tasks are refined or expanded as the detail expands or requirements change.
• Progress is continuing as expected, and problems are being communicated for unexpected issues.
• Each team member's experience is appropriate for the level of work assigned.
• Technical or personal problems are quickly addressed, or adjustments are made to the team.

We will be the first to admit that full-fledge project management should not be on a technical practitioners plate. When the team gets so large, or the burden gets so great that it interferes with building the right technical solution, additional resources should be provided to the team for tracking the project. We leave it up to the reader to decide when that occurs. The key here is communication, communication, communication within the project team. Understanding what is going on within the project, what is the current status of any components, and what issues are being worked through currently?

Of course, there is a corollary here: Non-technical leaders should not expect to run the technical design and development of a project; instead, they should defer the technical decsions to the architects and developers. For technical leaders, project planning, estimating, and tracking are required in addition to having strong technical and technical leadership skills.

About the download

The download that accompanies this article consists of two spreadsheets that might be helpful in your project:

• An estimation spreadsheet, to help estimate the amount of effort it could take to create some of the components of your project
• A tracking spreadsheet, to provide daily status and track the progress of your project.

Both of these spreadsheets are discussed in detail later in this article.

Back to top

Building a project plan

Building a full project plan requires understanding all the activities and tasks that will be necessary to complete the project. Developing a good Work Breakdown Structure (WBS) can be the core of the approach. Identifying a list of core tasks will help you call out all the other details in your planning phase, project plan, estimation, and tracking. Trained project managers usually follow an entire methodology to build the project structure, including understanding the business value, milestones and tasks, resource allocation, and so on.

More then likely much of the information for the plan has to be obtained from the bottom up. There is no way that you are or a project manager is going to know all the details of each sub-area. Some sub-teams might not even know all the tasks and dependencies they will face. Like most aspects of portal projects, experience plays a key role in determining the success in your project.

Getting started

Building a real project plan is an awesome task. It is one thing to create a simple list of tasks that need to be accomplished. It is quite another to build a detailed project plan with resource allocations, dependencies, and milestones. Even when the plan is complete, the task of managing to a plan requires skill and experience beyond many project managers.

For technical folks, helping to build a project plan by identifying the tasks and activities and working with your project manager is a reasonable request. Project managers often will not know the level of detail that is required. Even technical folks might not even know the level of detail until the requirements and capabilities are more defined, and many unknowns have been researched.

There are different schools of thought about building project plans. Some practitioners do not believe that the project plan should be a step-by-step procedure for doing all activities; they believe that if you are getting to that level of detail then you have gone way too far. Rather, they believe it should be at a level where accountability and tracking results are comfortable for the team. Of course, this is fluid depending upon how detailed you want to make your plan. Tasks that are only a few minutes or an hour might need to aggrated into a bigger line item.

Many project managers have different "rules of thumb" for the maximum duration of any one task, but a common one is that most tasks should not exceed two weeks. Some project managers prefer tasks broken down into one-week blocks, which gives them more opportunity to catch issues and track progress. The maximum duration is not that important; instead, track progress in a meaningful way where everyone understands his or her role, and people can make measurable progress in a reasonable manner. Otherwise, you may find the team spending 80% of the time to get to 80% complete, and another 80% of the time to get to full completion!

Tasks at a high level such as "Build QA Environment" are OK for a work breakdown list. At some point the list should evolve into sub-tasks that help you identify when a problem has occurred; for example a list of tasks such as these. 1. Install WebSphere Portal 2. Configure database 3. Configure LDAP and security 4. Cluster WebSphere Portal

If the team is late on item number 3, it is an simple effort to identify that the LDAP server has not been built out yet, and to measure how far it will put you behind schedule.

One technique for building the project plan, which does not require fancy project management software, is to build an outline of the project. Any word processing software or spreadsheet that lets you create various levels of indentation is fine. In fact, we built an outline to create this article series. Remember when you had to write a "research paper" in junior high school and your teacher made you create an outline first? We all hated it—we just wanted to write the paper and get it over with. (But maybe, just maybe, Mrs. Smith --or whomever your teacher was--really had something meaningful to teach us.)

In the example above, you would start with Build QA Environment, and then you put these four tasks indented under it. Then you realize that, whoops, to cluster the portal, you need to install WebSphere Portal on multiple machines and you also want a separate HTTP server. Just add those tasks. Suddenly you realize that you need the hardware, so you add an item "Confirm with operations that the machines have been allocated". Warning: If you have a project manager putting this into some fancy project management software, he or she might hug you.

As you work out your task list, remember to include the non-coding work that you have to do, such as writing up design documentation, testing, or just figuring out something new.

Identifying the tasks

Project plans are never "one size fits all", so we are hesitant to provide one here. However, it might be helpful to see some of the major tasks that you could include in your own plan.

• Project Startup
• Staffing
• Training
• Objectives
• Solution Definition
• Portal workshop
• Product selection
• Software components
• Hardware platform selection
• Creation of Project Standards
• Development
• Change management
• Testing
• Deployment
• Environment Setup
• Development
• Build
• Integration
• QA
• Stage
• Production
• Development
• Design
• Development
• Build iterations
• Deployment and Test
• System test
• Performance testing
• Deployment
• Production Release
• Final builds
• Deployment
• Staged go-live

The details are, of course, implementation-dependent, based on your specific project needs and requirements.

We cannot overstress the need to get some experienced practitioners on your team, especially if you have an aggressive project on a tight deadline. Product and portal development expertise could be necessary to help call out the details of a project plan. Knowing the installation order and configuration of the software components is important, as is being able to accurately estimate the time required to complete various tasks. Not having the right expertise on hand is not necessarily fatal to your project. However, if you don't have it, you need to budget more time for training, learning, and working out issues.

Defining roles

To define the roles, you need to know the roles that are needed on a team, when different roles come into play, and the focus of each team member. Building a good staffing plan in advance can ease some pain and suffering, in the long term, from overburdened team members trying to take on too much. Many of the roles that are necessary in a portal project are similar to those needed in any enterprise development effort. These include expertise in all areas of the project lifecycle, as well as deep technical skills in specific areas. Here are some roles to consider:

• Project sponsor
• Project manager
• Business analysts
• Information architects
• Graphics designers
• Architects
• Technical leads
• Developers skilled in portal development
• Build and deploy specialists
• Infrastructure and operations specialists
• LDAP and security specialist
• Database administrators
• QA and performance testing team members
• Content authors and editors
• Infrastructure and operations specialists

OK, so that is the short list! Proper planning includes ensuring that the right resources are available at the right time for your project. If your team is experienced with building Enterprise Java applications, then you understand the need for all of these different skills. If this is your first project, then take at look at part two of this series: The Portal Workshop for help on getting a handle on what you need.

Applying the 80/20 rule

Too much detail can overwhelm even the most meticulous planner. In Part 2 we mentioned the 80/20 rule. The essence of this rule is that only 20 percent of the activity in your project really matters. Project managers know that 20 percent of the tasks take up 80 percent of the activity. We see this way too often in projects which get overwhelmed by details that are of no real concern, and in projects that try to bite off more then they can chew. Projects that try to do everything in the first release are headed for trouble. Teams experienced in portal projects know this from experience, usually by having lived through a troubled project themselves. The trick is to try to work the project in stages.

Figure 1 shows an example of how you might approach portal projects.

We are not suggesting that you should completely ignore the other 80 percent of your requirements; rather, we are suggesting you focus on what matters most. Even within the major tasks, look at the subtasks that are going to require the most work. These types of activities are the most important to track within your project lifecycle. Break the other functionality into groups and use iteration to release it to your users over time.

Back to top

Estimating the work

In our humble opinion, the task of estimating on most portal projects can only be done accurately with experience. There are many different estimation techniques available from which to choose. In many cases, these techniques require advanced training in the approach, and some effort to perform correctly. Experience in the field is also key, and very relevant to the strength of your estimates. The more experience you have with the types of tasks that you are estimating, the more accurate your estimates are going to be. Our goal is usually to create some quick and dirty estimates that can be refined later, and then to track our estimates and see how things are going according to plan.

Traditionally, we have provided a single ballpark estimate for different tasks, and then added or removed some percentage depending upon the skill and experience of the person assigned to each task. You can also use some basic heuristics, depending upon the entire team dynamics; that is, who is going to lead the team and what is his or her level of experience? The design of the code comes into play in estimating the complexity of the design, how far out-of-the-box the application is going to have to be customized, and how firm the requirements are. All of those questions and more play a significant role in determining how long this project is going to take--from design to deployment.

Recently there has been some discussion around trying a broader way of estimating which can make more sense in an initial estimate situation. It lets the architect or development lead create high, low, and (more importantly) most likely estimates for a task or component. Let's look at several estimation techniques.

Putnam Distribution Estimation Method

One approach to estimation is based on the Putnam Distribution Estimation Method, which represent total development time from inception through unit testing. The method depends upon the following formula:

  EV = (O + 4L + P) / 6 
 

where EV=Derived Estimate, O=Optimistic, L=Most Likely, and P=Pessimistic.

We have found this to be a very accurate approach in some situations. It is well received by many project managers and upper management because you deliver a range of estimates, rather then a single hard and fast number, which might not be very accurate.

Of course, most folks, in a very optimistic fashion, when looking at such a distribution will focus on the Low Estimate. While we are all for optimism, reality dictates that the Most Likely Estimate is really more useful.

You can build this estimation method into your tracking spreadsheet, or you can use it in a separate form. It can be formalized across the project or can be used as a guide by you in your own projects.

Figure 3 shows an example of the estimating spreadsheet.

One thing to point out is that pessimism can actually be very important in this situation. Many team members will tend to be very optimistic knowing that there is an impending deadline. This will probably not be very realistic in real-life, and will skew your estimates and planning, setting up the team for failure.

In the following sections we will talk about how to break down your components or requirements to estimate tasks. The main focus is to be able to answer questions such as:

• What are the tasks?
• Who is working on a particular task?
• What issues are they facing?
• How they are progressing?

Function based estimation

Function based estimation is probably the easiest to understand from a portal perspective. It begins by understanding the major components within your application, and then breaking down those artifacts into sub-components and tasks. You can usually identify the major components in the task list by different types of portlets, the number of portlets, or any back-end services that are required. Many portal projects require a number of services such as Portal Services, Singletons, or EJBs that provide access to resources outside the portal framework.

Depending upon how the breakdown of tasks occurs, this approach may or may not take into consideration many of the infrastructure tasks that the project may depend upon. In many projects, especially new portal environments, portlet development is only about a fourth of the effort that is required to deliver a production environment. However, if your infrastructure is already setup and in place, and the project is simply providing some new functionality, then this approach might be appropriate for your project.

A common approach is to perform a scoping and sourcing exercise in which you outline the requirements and effort that will be necessary for each portlet. You can also analyze the dependencies and then estimate the entire effort.

Sourcing and scoping

Sourcing a portlet is the act of determining which resources the portlet interacts with. For example, does the portlet display data from some database or Web service call? Scoping is related but requires additional information. Do multiple transactions need to occur while a user is interacting with the portlet? Some other questions you might try to answer in these two exercises are:

• What type of content will the portlet display, and is it single or multiple items?
• What source(s) of the content or data that the portlet will need to access, such as back-end applications, data, or services?
• Is personalization, multiple device, or multiple language support required?
• Will this portlet interact with other portlets? If so, what are the messaging and design constraints involved?
• What are the number of states, views, and JSPs required? Are Edit or Configure modes required?
• Which API, Framework, or tooling will you use for development?
• What are the access control requirements, if any?
• Is any caching required or necessary?

You can see that this is a lot to think about, especially when you multiply this effort by the number of portlets in your project. You might be able to think of the portlets as separate applications, and then divide some of the scoping work among different team members to make the process more efficient. The development leader or architect should be stay focused on any cross application dependencies or areas where resources can be combined. This is another area where the 80/20 rule might apply; focus initially on the most important portlets, and leave the others to a follow in later releases.

OK, we know most of you are thinking, "My business or executive sponsor wants all of the functionality, not just 20 percent!" We agree that this is important; otherwise they would not sponsor the project at all. This is where your negotiation skills come into play. The success of your project is greatly increased as you reduce the scope, but that doesn’t mean that the initial release has to be the final one. Build your project in phases, and release in increments. A smaller set of functionality that works well is much better then everything that functions poorly, or not at all. Remember, you are the one they are going to come to if there are problems. Following the phased approach keeps your priorities in order and lets you clearly accomplish things in a reasonable time frame, with much less risk to your career.

Integration based estimation

Many portal projects are really projects in which customers want to integrate many different applications and resources into a single interface for their users. Integration based estimation approach can help you focus on the most time-consuming tasks within your project, and integration tasks often take most of the time in a project. Setting up the portal infrastructure within your environment can be a complex integration effort. We hear customers say, "I just want it set up, out-of-the-box.". In reality there is no such thing as out-of-the-box, once you start to configure the portal for your specific organizational environment. Custom LDAP and database requirements, Single Sign-on, and content feeds, at a minimum, all present challenges in getting the initial portal set up.

Using an integration-based approach can be helpful for your first attempt at building a portal. Expertise is often required in building a project plan that outlines all of the tasks that will be required for your portal project, so you seriously want to consider how you resource your project. The task breakdown could be similar to what is done in functional based estimation; the difference is you have a greater focus on the integration components or services needed by the portal, and on the installation of the portal environment.

This approach focuses on the tasks that need to be done by infrastructure teams for both the portal and for any components with which the portal interfaces. Do the DBA’s need to set up a database for the portal? Can you use the existing LDAP hardware, or do you need to purchase and install additional hardware? Do you need any custom development for security or user repository (LDAP) integration?

All of these items are integration focused and have different dependencies then traditional development line items. Also, there tend to be other teams or people involved in the success of the integration effort. For example, more detailed design documents may need to be created to ensure that all teams are working toward the same goal.

Agile based planning

The tag line on the Agile Alliance Web site (http://www.agilealliance.com/home) banner says, "To satisfy the customer through early and continuous delivery of valuable software". These well-chosen words sum up the heart of agile development. Although it can take many forms, most agile development variations follow the simple premise of continuous development and integration throughout a project lifecycle.

The Agile Alliance is defined as follows. "The Agile Alliance is a non-profit group dedicated to the promotion of agile development. The guiding principles created by the alliance are contained in the Manifesto for Agile Software Development", which begins as follows:

At first glance, these words may be enough to make a project manager cringe. Services engagements generally survive through the list on the right. Agile development appears to be very much a contradiction from the conventional approach. However, let’s consider the final statement, "That is, while there is value in the items on the right, we value the items on the left more."

In a perfect world the list of items on the left would, and probably should, be the governing criteria for any development process. Because we know that this is difficult position to follow within many budgeted engagements, perhaps we can modify our approach to look at agile methods as a way of incorporating the items on the left in a way that won’t disregard the items on the right, and subsequently kill the project or budget. For example, let’s examine the last pair of items in the table:

"We value responding to change over following a plan."

Let's assume that we all agree and understand that projects change. Requirements might be gathered incorrectly; dependencies can be misunderstood; technology or integration points may vary; or the customer can simply change his or her mind. Understanding this change and incorporating some amount of flexibility into your project can help absorb or mitigate change in such a way that you can actually embrace it rather then wait with dread.

Agile estimation enables you to adapt to real-world conditions when you are planning in an uncertain world. This flexibility is imperative in situations where requirements change daily, while the project deadline looms ahead. Agile development also lets you focus on the most difficult or most important features first, and then easily add new portlets or applications over time as project resources allow.

This approach requires good prioritization of the functionality within your project. One of the keys is short iteration cycles where change is incorporated into the next cycle, if it is important enough to be included. Additional functionality can be added through multiple iterations, which allows for change at any point before the next cycle begins.

You might encounter organizational barriers to implementing an agile approach to your project. Many executives and project managers are unsure of the validity of agile processes and question whether they will deliver the same output as a traditional project. Agile methods are designed to accommodate flexible and changing requirements; for example, the change which happens when customers don’t know what they want. Other methodologies, which rely on more up-front time in an engagement, may nail down requirements for the rest of the process, but they might not actually be what the client wants when you get to the end.

Recapping the approaches

The approaches outlined above are simply recommendations, based on our experience, for how teams might do their project planning. There are no hard and fast rules for which approach you take and when; each approach has advantages at different times within your portal lifecycle.

• Function based estimation can be a good approach after you have your infrastructure in place and are looking at adding new portlets or components to the portal. Depending upon how aggressive your first portal project is, you may want to skip this approach for that initial project, or just use this approach for part of the project.
• Integration based estimation focuses on getting the portal running in your environment. This might be best for your first portal project where the focus is on integrating the portal within your organization, or for major integration efforts within a portal project.
• Agile based planning could be considered after the portal environment is set up and you are delivering delta releases. This works best with a project sponsor or management team which prioritizes schedule over function…but, then again, how many projects don't start with an end date in mind? While Agile approaches are really designed to handle project change, most of the time, the end date and a percentage of the function are mandatory, and other function can be adjusted as time allow…this may be where agile planning fits best.

Back to top

Tracking project progress

How can technical practitioners assist in tracking the progress of the project without using a full-fledged project plan or software? Over the years we have perfected the art of using a work break-down, or task-based spreadsheet. This highly customizable document helps you to list and estimate pieces of work very early in the project. Then you use this data to assign work to different developers on the team, and to track their progress during the project. This approach provides the following benefits:

• A spreadsheet is very easy to use and maintain, unlike the more formal project plan which quickly goes stale and is never easily updated. You see an example of this later.
• Project managers love it (really!) when you have these initial tasks and estimates on hand early in the project for them to feed into their project plan.
• The form can be used to feed into design as well as to track the progress of the team. The lead developer or architect is usually the one to build and maintain the spreadsheet. He or she can use it to assist in breaking out different components (portlets, services, and other components) that will be needed in the design.
• The form is compact (usually one or two pages) that can be carried around and updated with current status as you talk to team members. Once or twice a week the changes can be incorporated into the document and a new one printed. This will probably occur daily in the early stages of the project, that is, in the design phase.

We believe that this type of spreadsheet can be used on any project with any type of methodology very effectively.

Defining the task list

The next part is to understand what tasks to actually put on the spreadsheet.[KEP3] Actually, this is the fun part. We break the form into sections and then we list the various components or tasks within each section. The sections can be broad object categories such as portlets and non-portlets, or a more granular, such as functional categories. For example, you might have some functionality with a large number of components that you want to track as a group. Some sections that you might include are:

• Security (for example, login and registration)
• Services (common portlet services)
• Portlets
• Content management
• Infrastructure
• Design
• Documentation

You can use this form to track more then just developing components. We often use it as a catch-all for all the project-related tasks, so we include documentation that needs to be generated or written, setup of the environments (such as staging, Q/A, and production), training, or any type of tasks that the project team needs to get done.

Day-to-day tracking

For the daily tracking, you can print the completed form, and carry it around as we talk with team members during the day. You add new work items and new issues, and make adjustments as the project evolves. On particularly complex projects, having this form handy at meetings or when stopped by the project sponsor is important so you don’t have to scramble to explain who is doing what, or to describe how work is progressing. A quick daily discussion with the developers can provide you with the latest status on different components.

Optionally, you can color-code the chart, and check off the completed items, to make it easier to get the status at a glance.

Some issues or problems that are flagged on your schedule should not be left to linger too long. Raising the alarm (real or imagined) is usually the right thing to do. Alerting managers, customers, or co-workers about a potential problem early is better then waiting until it’s too late. In this case, color-coding the lines can be very effective. Green (on tract), Yellow (possibly in danger of missing the schedule), and Red (stopped, possibly needs immediate action) are effective colors to make an immediate visual impact during discussions about the project. (The colors on our sample do not reflect anything particular except to distinguish between different areas of interest.) Remember though, keep it as simple as possible. You don’t want to get caught in a trap where you are constantly updating your form.

On occasion we have had development teams make jokes because the leads are never without their tracking spreadsheet in hand, always asking questions and making notes. As long as things do not become overly managed, our advice is to let them laugh. It helps to release the pressure developers are usually already under.

Getting more help

Software Services and IBM Global Services can help in many capacities; having collectively worked on hundreds of projects, they understand the nature of what it takes to plan and build a portal. Assistance can take a variety of forms, such as helping to define and break down the tasks and activities, or providing a sample project plan that can be adapted to your project. Starting with a template project plan is fine; however, every project and environment is different.

They can also help sort through the many components and configuration requirements which are typical in most portal projects. Every set of project requirements is different, and may require a customized integration plan. That is, after all, what a portal project is all about—integrating people, content, and applications that might never have been available previously in a single location. Portal software, by itself, is quite straight forward; it is the complexity of integrating diverse systems that leads to most of the time in the project schedule.

Our goal here is not to push IBM services on you or to inflate your project costs. In fact, getting experienced help early in the project lifecycle can help to insure the success of your project and reduce your overall project costs. Because most portal projects are enterprise in nature, having "been there, done that" is a good thing. Starting off with someone experienced in portals can save several months in the overall effort. For any project (except for perhaps the smallest ones) a cost-benefit analysis of having at least one experienced practitioner on your team is probably a winning proposition.

Back to top

Conclusion

Keeping in theme with our discussion there are several additional recommendations that we can offer to project leaders and sponsors.

1. Keep it simple. Make sure the users, the project team, and the executives see results quickly.
2. Select an estimation approach. The best one to use is based on your experience in building portals.
3. Use an iterative approach. After adding each integration point, test functionality and performance to ensure alignment with expectations.
4. Respect it like any other complex application or infrastructure project. Appreciate that this one can be more easily decomposed into manageable pieces.

It is very easy to get overwhelmed when starting an initial portal project--so many things to do, with little time to deliver the final product. Planning is key, not only for tracking your progress, but to insure that you can finish on time in the first place.

Back to top

Download

Description	Name	Size	Download method
Sample spreadsheets	planning-samples.zip	10 KB	FTP|HTTP

Information about download methods

Resources

• developerWorks WebSphere Portal zone: Find more resources to help you develop portals and portlets.
  
  
• Agile Alliance Web site: describes the organization and includes the Manifesto for Agile Software Development.
  
  
• Agile Software Development: Principles, Patterns, and Practices. Robert Martin. Prentice Hall, 2003.
  
  
• Extreme Programming Examined. Giancarlo Succi, Michele Marchesi.
  
  
• Extreme Programming Installed. Ron Jeffries, Ann Anderson, Chet Hendrickson.
  
  
• Web services programming tips and tricks: Project planning tips
  
  
• Program management: Different from project management
  
  
• The Comparison of the Software Cost Estimating Methods
  
  
• IT Project Estimation References and Resources
  
  
• WebSphere Portal in Action: Read Joey Bernal's blog on developerWorks.
  
  

About the authors

Anthony (Joey) Bernal is an Executive IT Specialist with IBM Software Services for Lotus, and a member of the WebSphere Portal practice. He has an extensive background in the design and development of portal and Web applications. He is the author and co-author of several books, including Application Architecture for WebSphere; Programming Portlets 2nd Edition; Programming Portlets, the IBM Portal Solutions Guide for Practitioners; and from a previous life, Professional Site Server 3.0. He also contributes to his popular blog, Portal in Action.

Ken Polleck is a Senior Practice Manager in IBM's lab-based Software Services for Lotus. He has 20+ years of experience at IBM in technical and managerial roles in software development and services. As a PMI-certified project manager, he has spent the last six years working with WebSphere clients to help them assess, plan, develop, and deploy over 500 WebSphere projects with his team providing hands-on mentoring and expertise to those clients. He lives with his wife, a WebSphere Software Development Release Manager, and three children in Raleigh, North Carolina.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Building a project plan
• Estimating the work
• Tracking project progress
• Conclusion
• Download
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers