The Best 7 Project Management Applications Online

Whether you are looking to organize your personal life at home or to collaborate on a team project with your coworkers, here are some of the best web-based project management software that can help you stay organized and on top of your work.

All online project management apps discussed here offer introductory free accounts so you can use them at home or school as well without requiring any budget. And since they are online apps, you can successfully manage your projects, tasks and deadlines from virtually any computer.

1. Basecamp
Keep up with what needs to be done on your project

Basecamp from 37Signals attempts to keep you focused on the tasks at hand with its task-centric interface. The main dashboard shows all the upcoming tasks and milestones of all of your projects organized by date.

While creating to-do lists, you can assign individual items to any of the team members or everyone. There’s a message board associated with every project where you can share project updates or even post questions without having to email anyone – it’s just like an online message board but accessible only to your internal team who’s part of that project.

Basecamp offers wiki-style Writeboards for collaborative writing. Project members can additionally chat with the group through Campfire which is like a web-based instant messaging tool that also save a chat transcript for reference later.

Basecamp offers a free account for 1 project with unlimited users but you cannot add documents and other files to the project. For additional projects and features, upgrades are available starting at $12/month. There’s no learning curve involved.

2. Goplan
Know how long you’ve spent on each task

Goplan is a task-orientated project management tool that provides a discussion board, calendar, document storage (with file versioning), timesheets, tasks and tickets (e.g. for bug tracking and resolution).

One of the very unique features of Goplan is that it lets you easily track the time you spend on different tasks. It works like this. When working on a particular task (or a ticket), you can start the timer inside Goplan (the clock icon) and update your status so that everyone in the team is aware of what you are working on. When you stop the timer, this gets recorded automatically in your time sheet.

When creating new tasks and tickets inside Goplan, you can attach documents and other files to the project. And if you have team members who aren’t part of the project, they can still add tickets to the project by simple emailing a note to a specific email address.

Goplan offers more projects with the free plan than most other project management apps. The free plan provides 3 projects for 2 users, and 100Mb of online storage space for your files. Upgrades are available starting at $10/month for additional projects, users, and storage.

3. Soshiku
Manage your school or college assignments

Soshiku is aimed primarily at high school and college students to help them keep track of all pending assignments and other school work.

The home page shows all of the assignments that are due today, as well as upcoming events and assignments for the full week. You can invite partners (or your classmates) and collaborate on class assignments within Soshiku itself. You can also attach files up to 50 MB in size with assignments.

Although other project management products can be useful for students, Soshiku is designed specifically for students with no extra features and it’s completely free (supported by ads).

4. Harvest
Track Time and Money spent on projects

With Harvest, you can easily track time spent on a task using the web interface or through dedicated desktop widgets available for Mac and PC. Harvest offers integration with Basecamp, so you can use Harvest’s time tracking features along with the other project management features found in Basecamp.

If you are freelancer who’s using Harvest to track the time spent on a project, you can use the same tool to directly produce invoices for your clients for your time and other expenses. Once an invoice is created, the invoice dashboard keeps track of all open, past due, and recently paid invoices.

Harvest offers a free account for one user with up to 2 projects, 4 clients, and unlimited invoicing, and then offers upgrades with unlimited projects and additional users and features starting at $12/month.

5. Co-op
Know what team members are doing right now

Co-op helps you track updates from everyone in the team inside a Twitter style interface. Team members can post anything in their status updates and it is visible to the entire team. The best part is that co-op includes built-in time tracking from Harvest (discussed above) so everyone know what you have been working on and for how long.

6. DeskAway
Know how your project is going with graphs and reports

If you want to keep track of your projects with graphs and reports, DeskAway could be a good service for you. DeskAway supports tasks, milestones, calendar, time sheets and file sharing. You can email all members of the project using DeskAway itself and the messages are also archived in a central location.

DeskAway offers detailed reports and graphs showing information about completed, overdue, and upcoming deadlines, as well as graphs showing your overall progress on various projects. You can also create an internal blog with DeskAway for team members.

DeskAway offers a free account for up to 3 active projects, 5 users, and 25MB of file storage but without support for issue tracking. You may upgrade starting at $10/month for accounts with more features including additional users, storage space and deskmail (a feature that lets you manage tasks via email).

7. Zoho Projects
Stay connected in a group project with social networking

There are quite a few things that set Zoho Projects apart from competition. For instance, if you already have your project plan created inside Microsoft Project, you can import the file into Zoho Projects and easily make that switch from desktop to web based apps.

Like most other Zoho services, you can log into Zoho Projects using your existing Google Account or Yahoo! credentials. Zoho Project is integrated with Google Docs so you can attach documents with your projects that are already on Google Docs. And like other online project management apps, Zoho Projects too offers an iCal feed of the project calendar so you can track milestones, tasks, etc. in Google Calendar or even Outlook.

With Zoho Projects, you can add tasks and milestones to a project, and communicate with your team through wikis, built-in chat, and forums (or message board). Each forum has a unique email address so you can post replies to forums posts via a simple email message.

The free version of Zoho Projects will let you create a single project with 1 wiki and 100 MB of file storage. The premium version of Zoho Projects offers support for timesheets, invoices and additional projects at $12/month.

Agile development methods and CMMI – Factors that Affect Perception - MISUSE - Part 2

Whether analyzing the CMM or CMMI, there is one thing shared by both works that makes them unique—they are models, not standards, for improving product quality and process performance.

However, for nearly two decades, the software industry has experienced the result of people misusing appraisal ratings as entry criteria, confusing appraisal ratings for measures of business performance,and misapplying a model as a standard in an environment in which products are created
to meet contractual requirements.

Used in this way, CMM and CMMI best practices were misinterpreted and misused. It is not an exaggeration to say that any approach to improve an organization’s achievement of business objectives in such an environment would have difficulty overcoming an emphasis on RFP requirements
and keen competition for multi-year contracts.

Does this situation mean that CMMI is wrong for software? Not in the least. It simply illuminates the following reasons why some perceive CMMI to be incompatible with

Agile ideals:

• The context from which the CMM and CMMI originated was specific to a particular customer base having unique challenges and characteristics of high risk and low trust.
  
  
• The CMM and CMMI were a new paradigm introduced into a large (and dominant) industry where paradigms, including the attitudes and beliefs associated with them, were in place for many years (e.g., command and control).
  
  
• Agile ideals developed as a backlash against the inefficient software development patterns that arose in this industry.
  

These points describe the context in which the CMM and CMMI were developed. This context enables us to understand some of the characteristics of the CMM and CMMI and how they have been used over the past two decades. While the language of CMMI, admittedly, may retain some of the flavor and phrasing of this context, each release of a CMMI model grows further away from these roots to embrace a richer and more dynamic set of contexts (Users of older model versions may not fully make the transition as new versions are released, and older beliefs and values may persist. Further, while CMMI and SCAMPI materials continue to evolve, it is simply not possible
to bring all users rapidly forward to the newer versions, government edicts and SEI encouragement notwithstanding.) Users of older model versions may not fully make the transition as new versions are released, and older beliefs and values may persist. Further, while CMMI and SCAMPI materials continue to evolve, it is simply not possible to bring all users rapidly forward to the newer versions, government edicts and SEI encouragement notwithstanding.

Further, this context is not the sole element determining how CMMI should be used, when and where it can be used, or what defines whether CMMI is being properly used. Nor for that matter, does this context determine its applicability in other contexts. The challenge is for the broader community to identify the practices and methods (or practice implementations) that enable organizational maturity in more dynamic contexts (e.g., internet commerce, social networking, and games development). An increasing subset of both CMMI and Agile method users are trying to do just that.

The Origins Of CMMI

Before receiving the “CMM” name, the first Capability Maturity Model-like framework was published in 1989 by Watts Humphrey in his book, Managing the Software Process. A few years earlier, the U.S. DoD announced a request for proposals (RFP) to address the excessive amount of money being spent on software that was either never delivered or delivered late with little of its expected functionality.

The contract awarded on the basis of the RFP was to establish what we know today as the Software Engineering Institute (SEI) at Carnegie Mellon® University. The SEI brought together representatives from academia, research, and industry to expose and promote practices demonstrated to be successful at avoiding the failures so beleaguering DoD software acquisition efforts. Carnegie Mellon’s framework of practices to address the DoD’s issue became the CMM. If we look at the genesis of the CMM, it predates the internet and nearly everything associated with internet technology. For that matter, CMM predates many software development, deployment, and infrastructure technologies, languages, and methods. We’ve all learned a lot in the past 20 years. When the DoD set out to address their “software dilemma,” the software world was different than it is today.

To color this context even further, everyone working to develop the initial CMM was looking for the solution to the “software problem” from the perspective that software is a component of a larger system and that if it failed, lives would be lost (e.g., aircraft, ships, weaponry, medical devices). Systems were evolved using careful and deliberate development paths according to lowerrisk, standardization-heavy and contractually-driven relationships between the developer and the customer.

In today’s frequent discussions of increasing globalization and the important role played by trust (i.e., level of social capital) in making effective collaboration happen across stakeholders, one might describe such a development context as exhibiting low trust. Users were typically not direct contributors to the evolution of the end product prior to field testing. They instead had to depend on the contracting relationship, requirements, and standards to deliver the product they needed.

This short history of CMMI focuses more on the past twenty years, but as in the case with Agile, the roots for many of the product development, project management, and process concepts found in CMMI have a long history. 7 This definition of trust may be clearer but more elaborate: “the willingness of a party to be vulnerable to the actions of another party based on the expectation that the other will perform a particular action important to the trustor, irrespective of the ability to monitor or control that other party” [Mayer 1995]. For the purposes of this report, the particular question being asked is whether there is a level of trust between the project and its customer that will allow them to effectively negotiate scope as the project progresses, without the customer requiring detailed accounts of project effort.

These comments may be an over-generalization, but they are intended to summarize the DoD software acquisition environment that existed at the time. Further, these comments explain why the practices in CMMI sometimes exhibit some of these same high ceremony and low trust characteristics found in the high-risk, government-contractor environment in which software failure could equal lives lost.Also, within the high-risk government-contractor environment at that time, the prevailing pattern of infrequent and monolithic deliveries contributed to the high costs associated with deployment, upgrade, and replacement (e.g., software embedded in fighter aircraft in the 1980s could not be upgraded over the air or over the internet). Hence, getting it right the first time was critically important.Furthermore, most of the organizations involved in this contractual environment were large organizations working on large complex projects.

Finally, the use of public money in government contracting (or similar high-visibility and highstakes situations) requires a level of accountability by all those involved that often drives all parties toward risk-averse behavior bordering more on protecting one’s own interests than on finding the most efficient win-win solution. Ceremonial but perfunctory activities help address the often competing and incompatible self-interests of all parties, but make operating in an open and transparent manner challenging, and reinforce the perception of low trust. Within a few short years, the CMM was expanded into several other models; these were point solutions developed to address non-software development projects. Also, the CMM and these variants increasingly became used internationally and by commercial industry. Organizations attempting to adopt more than one model on any given project quickly realized the challenges of
doing so and petitioned the SEI to consolidate the various CMMs into one model, which in 1998 led to a joint industry, government, and SEI team to create CMMI.

Of course, over the years that the CMM and CMMI have been maintained, inputs on what constitutes good management and development practice have increasingly come from a wider variety of industries and from users around the world. As a result, new ideas, standards, and practices are continually being incorporated into what is now the CMMI Framework.

The Origins Of Agile Methods

The cornerstone of Agile methods originated long before the World Wide Web and collaborative technologies (e.g., wikis and instant messaging). This cornerstone is iterative and incremental design and development (IIDD), a method adopted by engineers over 75 years ago.

Early adopters of IIDD included Department of Defense (DoD) engineers who engaged in propulsion-related research and development, which included engineering activities tied to hardware not software. An early progenitor of IIDD was Dr. W. Edwards Deming who began promoting Plan-Do-Study-Act (PDSA) as the vital component of empirical engineering. Early adopters of Deming’s teachings in the aerospace industry include NASA (National Aeronautics and Space Administration) and the US Air Force, each of which developed entire systems using time-boxed, iterative, and incremental product development cycles.

As early as the mid-1950s, IIDD was used in software development resulting in business benefits such as “avoiding management discouragement” and “increasing customer satisfaction.” In fact, a large number of early software development projects, which were often experimental and explorative, shared many of the attributes of today’s Agile methods. However, in a systems world dominated by mainframes, COBOL (Common Business-Oriented Language), and the demand to process large and complex datasets, procedural top-down design and development methods dominated and were perceived by many to be the standard. This situation was influenced by the procedural nature of DoD standards and the proliferation of fixed-price contracts awarded to suppliers of complex DoD systems (the predominant consumer of computer software at that time).

In 1976, Tom Gilb argued that evolutionary development resulted in superior software delivery in his book Software Metrics and launched a movement toward agile, light, and adaptive development iterations that provided rapid results and more frequently visible business benefits. This short history of Agile methods is provided for the benefit of those who might mistakenly believe that Agile methods are a recent innovation without deep conceptual roots. For a complete history, there are books that describe the events of the past seventy-five years that also contributed to the success of Agile methods.
By their nature, the parties to fixed-price contracts assume an unchanging project scope in unvarying development and use environments. This nature makes it difficult to later modify project direction (without highceremony activities) to take advantage of newly-discovered needs and constraints or new technologies.

As the state of software engineering matured, more formal applications of IIDD became available for example, in Barry Boehm’s 1985 release of The Spiral Model of Software Development and Enhancement.

Throughout the 1990s, IIDD gained broad acceptance in the software community in various forms, including rapid prototyping, rapid application development (RAD), and rational unified process (RUP). The seeds of most modern Agile methods were sewn throughout this decade. While most may not expect it, innovative and Agile methods began in the large information technology (IT) shops of several large companies, including an automotive manufacturer and an overseas
bank. XP (eXtreme Programming) began at Chrysler Corporation in 1996 on a project staffed by IIDD advocates Ron Jeffries and Kent Beck, while feature driven development (FDD) started at United Overseas Bank in Singapore, one of Asia’s largest banks. With pair programming and refactoring as XP’s most celebrated features, XP became one of the most recognizable methods of the Agile family. Before the end of the decade, it was clear to many businesses and software engineers alike that in many settings, face-to-face communications, rigorous customer interaction, small rapidly moving teams, and frequent delivery of software ultimately produced superior software.

This enlightenment was occurring simultaneously elsewhere and so-called lightweight methods proliferated with names such as Scrum, Crystal, FDD, and others.
With the proliferation of IIDD methods came the need to coordinate and compare these methods by those interested in their growth and sustainment. The result of this need was a “meeting of the minds” among leaders who were principally responsible for the theory and application of each method.

A group of leaders met, including Kent Beck, Ron Jeffries, Alistair Cockburn, Jim Highsmith, Bob Martin, Mike Beedle, Ken Schwaber, Jeff Sutherland, and others who represented the most successful of the new lightweight methods. Modeling their meeting after an earlier meeting of XP enthusiasts in Oregon the year before, these leaders gathered in the Wasatch Mountains of Utah to ski, relax, and ultimately author the Manifesto for Agile Software Development.
A subset of the Manifesto authors, together with others like Mary Poppendieck, went on to form the Agile Alliance, a not-for-profit organization dedicated to encouraging the adoption of agile methods. The Agile Alliance primarily focuses on organizing the Agile Conference in the United States every year.

While even the organizers of the Utah event expressed skepticism of its outcome, the sessions were a success. The Manifesto documented the guiding principles of Agile development and defined a philosophy around a set of existing methodologies. While the first Manifesto for Software Development focused on programming, three years later original Manifesto authors Jim Highsmith and Alistair Cockburn gathered a similar group of early Agile adopters, including David Anderson, Mike Cohn, Todd Little, and others to establish a set of six management principles known as the Project Management Declaration of Interdependence (DoI) [Anderson 2005b]. The 15 authors of the DoI subsequently formed the Agile Project Leadership Network (APLN), a notfor-profit organization dedicated to encouraging better leadership and management in the IT sector and software engineering profession.

SOFTWARE ENGINEERING INSTITUTE. The Manifesto and Interdependence publications, books written by their original authors, the formation of not-for-profit organizations to promote the Agile approach, and the widespread use of the internet for research by software practitioners, has resulted in the rapid growth and broad adoption of Agile methods throughout much of the software engineering profession. Some methods, most notably Scrum, continue to grow beyond the software industry into professions that desire the benefits provided by the same basic IIDD concepts first pioneered by Deming and his predecessors.

A section of the book “CMMI® or Agile: Why Not Embrace Both” provides the basis for much of this article.