It isn't all about the code?
This is the coneblog journal and related categorized archives. You can read the blog as written back to front, or browse the categorized archives at right - check out the about categories for guidance on that is where. For a quick overview of the types of content you might run into, check out the Best of coneblog - some of my personal favorites.
Entries in Best of coneblog (24)
“Chunking Iraq” – Scope from a PM Perspective
“Chunking Iraq” means looking at the Iraq war from a Project Manager’s perspective, and using the scope chunking technique to think about the project scope alternatives available to the war planners.
Last time we talked about different ways to Chunk a project into manageable bites. Some options were by geography; by interface; by user group; by benefits. Can we apply any of these to Iraq?
Larry Cone
in Best of coneblog, News & Events
|
Post a Comment
“Architectural Elitism” and the Build vs. Buy Decision
I continue to see organizations choose to do a major custom development when viable alternatives are available in the marketplace. The reason given is usually that “our requirements are unique”. The real reason, especially in large organizations, is very different.
Larry Cone
in Best Practices, Best of coneblog, Case Studies
|
Post a Comment
Stop Ugly Code Before it Starts!
You have seen ugly code. You have probably written some yourself. The Tragedy of Ugly Code has reached epidemic proportions since the advent of Java and object-oriented techniques.
Larry Cone
in Best of coneblog, Humor, Kool Stuff, Project Manager Tools
|
Post a Comment
Punchlist for a “483” – Standing on the Rock
We are pushing toward the finish of this Incident Reporting System project. I’m working the Punchlist with my Client PM counterpart, and we are knocking items off faster than they are coming on.
Larry Cone
in Best Practices, Best of coneblog, Case Studies
|
Post a Comment
Punchlist for a “483” - The Main Chance
We were deep into design in the “483” project. As described, in this project process the Design Document is done last. So, once we had a good idea of the data design, we started building screens. We used an iterative process with multiple client reviews in short order, as time was limited. The Tech Writer started to document the data model, and build a Glossary – the most overlooked part of project documentation. And I worked on the Issues List, which later ended up saving my butt.
Larry Cone
in Best of coneblog, Case Studies
|
Post a Comment