Archive for category Project Management
New open source project management tool for large-scale enterprise systems
Posted by Shahid N. Shah in Methodologies & Frameworks, Project Management on July 21st, 2009
I just ran across the new Endeavour Software Project Management solution; it seems to be a pretty feature-packed web-based open source package to manage the creation of large-scale enterprise systems. Unlike most large project management solutions that assume waterfall approaches, Endeavour’s designers understand that most modern applications are developed in an iterative and incremental development process and it supports agile processes by providing administration for software process artifacts, reports and collaboration among many different stakeholders.
It’s still quite rough around the edges but I think it’s a great start.
Cloud Computing: DISA’s Operational Perspective
Posted by Shahid N. Shah in Cloud Computing, Methodologies & Frameworks, Project Management on March 8th, 2009
DISA’s been doing some excellent work around global hosting and creating centralized data centers for use across the government. A couple of weeks ago they presented their cloud computing operational perspective at the GSA Cloud Computing Quarterly IT Forum.
Their presentation is worth reviewing:
GAO reports on Agencies’ rebaselining projects
Posted by Shahid N. Shah in Methodologies & Frameworks, Project Management on August 26th, 2008
A fellow EA at the Army sent me a link to the GAO’s recent IT report entitled “OMB and Agencies Need to Improve Planning, Management, and Oversight of Projects Totaling Billions of Dollars“. The study’s introduction says it was needed because:
…the Office of Management and Budget (OMB), which plays a key role in overseeing the federal government’s IT investments, identifies major projects that are poorly planned by placing them on a Management Watch List and requires agencies to identify high-risk projects that are performing poorly (i.e., have performance shortfalls). Having accurate and transparent project cost and schedule information is also essential to effective oversight. At times, changes to this information—called a rebaselining— are made to reflect changed development circumstances. These changes can be done for valid reasons, but can also be used to mask cost overruns and schedule delays.
It’s worth reading and getting our hands around what the legislative side thinks about our IT projects. Their summary indicates rebaselining is a major issue:
In its rebaselining review, GAO reports that 48 percent of the federal government’s major IT projects have been rebaselined for several reasons, including changes in project goals and changes in funding. Of those rebaselined projects, 51 percent were rebaselined at least twice and about 11 percent were rebaselined 4 times or more. In addition, while the major agencies have all established rebaselining policies, these policies are not comprehensive. Specifically, none of the policies were fully consistent with best practices, including describing a process for developing a new baseline and requiring the validation of the new baseline. Agencies’ policies varied in part because OMB has not issued guidance specifying what elements these policies are to include. In its report, GAO makes recommendations to OMB to issue guidance for rebaselining policies and to the major agencies to develop comprehensive rebaselining policies that address identified weaknesses.
Not exactly a damning statement but certainly something we should be mindful of as we look forward to our new EA submissions in the figure. With some changes expected with the coming presidential transition it’s unclear what OMB’s direction might be but even if specific policies aren’t announced, if we just use standard best practices on our side we should be ahead of the curve.
If you can’t repeat it, don’t bother automating it
Posted by Shahid N. Shah in Project Management on July 20th, 2008
There’s been plenty of discussion in both literature and general media about “most software projects failing.” There are plenty of reasons for failed projects: from inadequate requirements gathering to poor project management to plain incompetence. Some of the problem starts at the C-Suite where projects are actually identified and started — for asking to automate (presumably with software) something that maybe has no business being automated.
My simple advice to most architects, CTOs, CEOs and CIOs about project management starts with a question: can you methodically and manually repeat the thing you are trying to automate? If the answer to that question is “no” then no PMO, no project management technique, not even the smartest most talented people in the world can help automate something that can’t at least be repeated consistenly manually.
This advice of asking a simple question about repeatability might sound so obvious as to not even bother asking it but it becomes perilous not to do so. At the heart of most failed software automation attempts is a failure to understand the workflow and gather the right requirements. That’s pretty easy to figure out. What’s not so easy to figure out is: why is the workflow so hard to gather requirements for? It’s probably because the workflow, while it seems consistent at the high level, isn’t repeatable enough consistently to describe in software. Perhaps parts of it are, but maybe the entire workflow isn’t.
So, as a senior executive that may not be leading the project, but may be greenlighting it, what you need to do before making a decision is have your project managers describe that they can clearly repeat (manually and consistently) what they are trying to automate. If not, get the process engineering guys in there to work on the process before the geeks get in there to work on the technology.

Recent Comments